- From: Wenbo Zhu <wenboz@google.com>
- Date: Wed, 14 Apr 2010 17:22:34 -0700
- To: "Roy T. Fielding" <fielding@gbiv.com>
- Cc: Mark Nottingham <mnot@mnot.net>, ietf-http-wg@w3.org
On Tue, Apr 13, 2010 at 11:08 PM, Roy T. Fielding <fielding@gbiv.com> wrote: > 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. 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 . > > 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. Such a clarification will be useful, given all the different implementations that exist today. - Wenbo > > ....Roy > >
Received on Thursday, 15 April 2010 00:23:05 UTC