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

Re: Transfer-Encoding in a HEAD response

From: Roy T. Fielding <fielding@gbiv.com>
Date: Tue, 13 Apr 2010 23:08:40 -0700
Cc: Mark Nottingham <mnot@mnot.net>, ietf-http-wg@w3.org
Message-Id: <71848746-51A2-4A8C-B5B6-E3C213DA7010@gbiv.com>
To: Wenbo Zhu <wenboz@google.com>
On Apr 13, 2010, at 10:39 AM, Wenbo Zhu wrote:

> On Tue, Apr 13, 2010 at 2:38 AM, Mark Nottingham <mnot@mnot.net> wrote:
>> On 13/04/2010, at 6:36 PM, Wenbo Zhu wrote:
>>>>> 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.
>> See step 1:
> 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.

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.

Received on Wednesday, 14 April 2010 06:09:09 UTC

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