Mailing-List: contact users-help@trafficserver.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@trafficserver.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Subject: Re: Cache problems
From: Patrick McManus <mcmanus@ducksong.com>
To: users@trafficserver.apache.org
Cc: Szymon Francuzik <szymon_francuzik@op.pl>
In-Reply-To: <4C3B2370.1010206@apache.org>
References: <4C36E8AA.5050309@cs.put.poznan.pl>
	 <DF46AF89-BD1D-4E25-B402-4719AFCD2A3C@gmail.com>
	 <4C370889.6030201@cs.put.poznan.pl>
	 <AANLkTinWW2-JoqrqfJ7QqtxzCvfcTXZ0yT7wjTkVBUn7@mail.gmail.com>
	 <4C373273.2060801@cs.put.poznan.pl> <4C373433.7030306@apache.org>
	 <4C3B110E.3030008@op.pl>  <4C3B2370.1010206@apache.org>
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 12 Jul 2010 14:09:23 -0400
Message-ID: <1278958163.2156.534.camel@tng>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

On Mon, 2010-07-12 at 08:15 -0600, Leif Hedstrom wrote:
>  I'd expect Apache to turn a response with no CL: header 
> into a TE: chunked response, no? Without either of these headers, what 
> type of transfer encoding is Apache returning? 

presumably it is relying on connection close, which is what you would
expect of a dynamic response to a 1.0 request. Perhaps TS is configured
to send 1.0?

nph instead of cgi is also one way apache will generally terminate with
close.. there are probably others.

I can certainly see TS not wanting to cache a response without a better
delimiter though - it is impossible to know if there was a server error
or not.