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

Re: Transfer-Encoding in a HEAD response

From: Mark Nottingham <mnot@mnot.net>
Date: Mon, 12 Apr 2010 08:31:06 +1000
Cc: ietf-http-wg@w3.org
Message-Id: <D9B41260-6395-4863-B6E5-947A864389AD@mnot.net>
To: Wenbo Zhu <wenboz@google.com>

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

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


which should clarify this.

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


Mark Nottingham     http://www.mnot.net/
Received on Sunday, 11 April 2010 22:31:39 UTC

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