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

Message length and caches

From: Willy Tarreau <w@1wt.eu>
Date: Mon, 26 Nov 2012 08:35:26 +0100
To: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20121126073526.GB22492@1wt.eu>

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 07:35:50 UTC

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