Re: Message length and caches

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" <grmocg@gmail.com>
> To: "Adrien W. de Croy" <adrien@qbik.com>
> Cc: "Willy Tarreau" <w@1wt.eu>;"HTTP Working Group" <ietf-http-wg@w3.org>
> 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 <adrien@qbik.com> 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" <w@1wt.eu>
>> To: "HTTP Working Group" <ietf-http-wg@w3.org>
>> 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