- From: <rlgray@raleigh.ibm.com>
- Date: Thu, 18 Sep 1997 10:12:04 EST
- To: HTTP Working Group <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
My interpretation of the spec is that the HEAD response should contain *exactly* the headers it would if the method had been GET. I have to admit that today our server does the same as Apache and Agranat, but assuming that others agree I plan to fix that. The scenario I imagine is a client that for whatever reason doesn't want to accept chunked; it issues head, sees that the document would be chunked, and changes the protocol version ot 1.0 for the GET. ** Reply to note from "Scott Lawrence" <lawrence@agranat.com> Wed, 17 Sep 1997 12:01:43 -0400 > > > >> It turns out that our server doesn't send either Content-Length or > >> Transfer-Encoding in this case (it does send Content-Length if it > >> would in response to a GET), and neither does Apache. My > >> interpretation of the above is that we should send the > >> 'Transfer-Encoding: chunked', but of course send no body so that the > >> CRLF-CRLF after the headers is the end of the response. > > >>>>> "RTF" == Roy T Fielding <fielding@kiwi.ics.uci.edu> writes: > > RTF> Apache determines whether or not it will send chunked data to the client > RTF> based on a rather long conditional expression, and testing for HEAD is > RTF> one of the conditions. Basically, since Apache won't be sending > RTF> 'Transfer-Encoding: chunked' in response to a GET request by an HTTP/1.0 > RTF> client (and about 10 other conditions), there is no useful purpose in > RTF> sending it in a response to a HEAD request by an HTTP/1.1 client. > > Yes, sending Transfer-Encoding in response to any 1.0 method is > clearly incorrect. I don't see what that has to do with whether or > not it should be sent to a 1.1 request. > > The questions really are: > > - Would it be usefull to clients to see the Transfer-Encoding > header field in response to a HEAD request, perhaps for the > purposes of anticipating what a GET would produce? Put another > way; is it ever a problem _not_ to get it? > > - Should the spec be changed specify the correct behaviour (either > to include it in the HEAD response and ignore it in the client, > or to omit it from the response in which case the client cannot > infer anything about what it would get in response to a GET)? > > -- > Scott Lawrence EmWeb Embedded Server <lawrence@agranat.com> > Agranat Systems, Inc. Engineering http://www.agranat.com/ > > Richard L. Gray chocolate - the One True food group
Received on Thursday, 18 September 1997 07:24:01 UTC