Re: Message length and caches

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
>  
>  
>  
>