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