- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Tue, 13 Apr 2010 23:08:40 -0700
- To: Wenbo Zhu <wenboz@google.com>
- Cc: Mark Nottingham <mnot@mnot.net>, ietf-http-wg@w3.org
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. ....Roy
Received on Wednesday, 14 April 2010 06:09:09 UTC