- From: Wenbo Zhu <wenboz@google.com>
- Date: Tue, 13 Apr 2010 01:36:03 -0700
- To: Mark Nottingham <mnot@mnot.net>
- Cc: ietf-http-wg@w3.org
On Sun, Apr 11, 2010 at 3:31 PM, Mark Nottingham <mnot@mnot.net> wrote: > > 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). 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). > >> - 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. Well, this is not directly related to HEAD response. > >> 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). If we agree that transfer-encoding is not applicable for HEAD response, then this interpretation would be wrong. Thanks, Wenbo > > Cheers, > > -- > Mark Nottingham http://www.mnot.net/ > >
Received on Tuesday, 13 April 2010 08:36:34 UTC