Re: Message length and caches

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

Received on Monday, 26 November 2012 08:10:27 UTC