Subject: Transfer-Encoding in a HEAD response

From: Wenbo Zhu <[email-masked]>
Date: Sun, 11 Apr 2010 15:05:42 -0700

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;
- or set Content-Length = 0;
- or set a manual Content-Length as if there would be no
chunk-encoding for the GET response.

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

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

- Wenbo

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 12 Apr 2010 08:31:06 +1000

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

> chunk-encoding for the GET response.

If they know the length, they should send it.

> is applicable for a HEAD response (as it is the case for

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

which should clarify this.

> 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/

---

From: Wenbo Zhu <[email-masked]>
Date: Tue, 13 Apr 2010 01:36:03 -0700

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

> which should clarify this.
Well, this is not directly related to HEAD response.

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

Thanks,
Wenbo

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 13 Apr 2010 19:38:06 +1000

See step 1:

> and any response to a HEAD request

Cheers,

---

From: Wenbo Zhu <[email-masked]>
Date: Tue, 13 Apr 2010 10:39:27 -0700

>> Well, this is not directly related to HEAD response.
Well, this brings up my original question: if C-L is considered a
valid header for HEAD response, then transfer-encoding should be too,
i.e. in the context of 3.4 Message Length.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 13 Apr 2010 23:08:40 -0700

> i.e. in the context of 3.4 Message Length.

Content-length provides useful information for resource testing.
Transfer-encoding does not.  Moreover, T-E is almost always
generated by the server's messaging subsystem, not the resource
handler, and requires an elaborate test of HTTP versioning prior
to use.  It is mainly for the latter reason that servers do not
send T-E in a response to a HEAD request.

I see no reason to change this behavior in Apache httpd, so my
preference would be to clarify in the spec that there is no need
to send T-E in a response to HEAD regardless of the value it
might have for a GET.

....Roy

---

From: Wenbo Zhu <[email-masked]>
Date: Wed, 14 Apr 2010 17:22:34 -0700

> send T-E in a response to a HEAD request.
This seems to be aligned with the definition of HEAD request - i.e.
its response contains metainformation of the resource, which shouldn't
include T-E .

> to send T-E in a response to HEAD regardless of the value it
Such a clarification will be useful, given all the different
implementations that exist today.

- Wenbo