Re: Transfer-Encoding in a HEAD response

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

See:
  http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-09#section-3.4

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

Cheers,

--
Mark Nottingham     http://www.mnot.net/

Received on Sunday, 11 April 2010 22:31:39 UTC