Re: Message length and caches

(or am I crazy? :) )

On Mon, Nov 26, 2012 at 3:13 PM, Roberto Peon <> wrote:

> Roy--
> That definitely solves part of the problem (there really need to be two
> status codes, one for the server and one for the point-to-point
> connection), but for a caching intermediary, it would like to know up-front
> if it should bother to put that data into the cache. I know that I wouldn't
> want to put anything framed with connection closed into the cache, and so
> having something propagate the nature of the worst point-to-point framing
> is probably useful.
> -=R
> On Mon, Nov 26, 2012 at 3:03 PM, Roy T. Fielding <>wrote:
>> In waka, each message ends with an 8bit status code -- it is
>> either the same as that given in the beginning or a new code if the
>> message was sent incomplete (on a request, it is used to indicate that
>> an upload is being aborted).  I send the entire code because I want
>> to distinguish between "origin closed connection" and "intermediary
>> timed out waiting for more data from origin".  I assume that something
>> similar could be accomplished in SPDY by ending the last frame with
>> some sort of unexpected upstream termination bit.
>> ....Roy
>> On Nov 26, 2012, at 2:36 PM, Adrien W. de Croy wrote:
>> in the case I was talking about, the intermediary already chunked the
>> data.  So it really has no option when the server closes.  It can't close
>> to the client without sending a 0 chunk, since that would turn a
>> potentially complete resource into an aborted one.  So it must send the 0
>> chunk.
>> Unless you're going to say any time the intermediary expects the server
>> to close it should not chunk the data to the client.
>> I think we're just stuck with this until 1.2 or 2.0 deprecates the
>> mechanism completely.  Has it really been that big a problem?
>> Adrien
>> ------ Original Message ------
>> From: "Roberto Peon" <>
>> To: "Adrien W. de Croy" <>
>> Cc: "Willy Tarreau" <>;"HTTP Working Group" <>
>> Sent: 26/11/2012 11:23:30 p.m.
>> Subject: Re: Message length and caches
>> I was understanding that Willy was suggesting that we potentially add a
>> recommendation (or stronger) about what an intermediary should do when it
>> has a response which is framed by connection close.
>> Specifically, if a response is framed by connection close, then, treat
>> the response as if it was uncacheable and attempt to convey to the client
>> that the originator of the response framed with connection close.
>> That indication could be accomplished by also framing with connection:
>> close, or it could take the form (if we extend the spec) of a new header of
>> some kind.
>> -=R
>> On Mon, Nov 26, 2012 at 12:09 AM, Adrien W. de Croy < <>
>>> wrote:
>>> Hi Willy
>>> it actually gets worse than this.
>>> Some intermediaries chunk emitted data if the server indicated it would
>>> close and sends no C-L (so that the intermediary can keep the client
>>> connection alive).
>>> Since that intermediary can't tell the difference between an abortive
>>> and normal close, it will send a 0 chunk on close.
>>> So the receiver of that message will never know what happened.
>>> So I agree with Roberto about use of TCP close as a protocol signal, but
>>> we're stuck with it.
>>> Adrien
>>> ------ Original Message ------
>>> From: "Willy Tarreau" < <>>
>>> To: "HTTP Working Group" < <>>
>>> Sent: 26/11/2012 8:35:26 p.m.
>>> Subject: Message length and caches
>>>> Hi,
>>>> When there is no explicit body length in a message, it is terminated by
>>>> closing the connection. As we all know, this causes some ambiguity for
>>>> the client because it doesn't know whether a response body is complete
>>>> or was truncated by anything along the path, including timeouts. Thus
>>>> I'm wondering if some caches make a difference between such responses
>>>> or not (eg: a cache could decide not to cache objects terminated this
>>>> way).
>>>> The reason is that we recently implemented support for gzip compression
>>>> in haproxy and I preferred not to add an explicit response end to
>>>> messages which did not have one for the reason above. This results in
>>>> not compressing such responses at all (since we would not emit the
>>>> trailing gzip header with crc, making all responses appear as
>>>> truncated).
>>>> Do some people think that this practice is paranoid ? Maybe after all
>>>> we could compress and chunk responses and make the client be certain
>>>> that the message is complete while we were not. It just makes me feel
>>>> a bit like lying to the client.
>>>> Depending on common practices and opinion, I think that we could add
>>>> a small paragraph in -p1 about this (eg: intermediaries should not
>>>> re-chunk a close-delimited response).
>>>> Regards,
>>>> Willy

Received on Monday, 26 November 2012 23:14:15 UTC