W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2010

Re: Transfer-Encoding in a HEAD response

From: Wenbo Zhu <wenboz@google.com>
Date: Tue, 13 Apr 2010 01:36:03 -0700
Message-ID: <t2v83c4e7ff1004130136jf1a5d098ncdac37ca1d9dbfa1@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: ietf-http-wg@w3.org
On Sun, Apr 11, 2010 at 3:31 PM, Mark Nottingham <mnot@mnot.net> wrote:
> On 12/04/2010, at 8:05 AM, Wenbo Zhu wrote:
>> I have recently noticed that many public websites, in responding to a
>> HEAD request, will:
>> - omit Transfer-Encoding from the response headers if the GET response
>> will be chunk-encoded;
>> -- or (as expected) set the Content-Length if the GET response isn't
>> going to be chunk-encoded;
> I don't think this is a huge problem, as the delimitation of the message is specific to that message; i.e., servers can and sometimes do generate a chunked message in one moment, and a C-L delimited one the next.
> That said, it would be nice if they send C-L when possible (the encoding is less useful).
This seems a reasonable argument, esp. proxy may choose to buffer the
response anyway. So, no transfer-encoding for HEAD response, and C-L
when possible (as an implementation concern).

>> - or set Content-Length = 0;
> Yes, this is a well-known (and hopefully, slowly disappearing) problem.
>> - or set a manual Content-Length as if there would be no
>> chunk-encoding for the GET response.
> If they know the length, they should send it.
>> While rfc-2616 doesn't require all the headers appear in the HEAD
>> response, the confusion here mostly lies in whether Transfer-Encoding
>> is applicable for a HEAD response (as it is the case for
>> Content-Length).
> See:
>  http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-09#section-3.4
> which should clarify this.
Well, this is not directly related to HEAD response.

>> To clarify, 7.4 (9.4/rfc2616) may state: "The metainformation
>> contained in the HTTP headers in response to a HEAD request SHOULD be
>> identical to the information sent in response to a GET request; and
>> any headers that describe message body should be applied to the
>> response of the GET request".
> I'm not sure what that means. It could be read to say that a client can blindly apply the headers they receive in a HEAD response to a subsequent GET response, which isn't true (and dangerous).
If we agree that transfer-encoding is not applicable for HEAD
response, then this interpretation would be wrong.


> Cheers,
> --
> Mark Nottingham     http://www.mnot.net/
Received on Tuesday, 13 April 2010 08:36:34 UTC

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