W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2012

Re: Message length and caches

From: Adrien W. de Croy <adrien@qbik.com>
Date: Mon, 26 Nov 2012 08:09:55 +0000
To: "Willy Tarreau" <w@1wt.eu>, "HTTP Working Group" <ietf-http-wg@w3.org>
Message-Id: <em2d22585a-756e-42d0-9b16-fdd23aaba418@bombed>
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.


------ 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
>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
>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).
Received on Monday, 26 November 2012 08:10:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:07 UTC