Re: Head response Transfer-Encoding: chunked?

>> 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/

Received on Wednesday, 17 September 1997 09:04:51 UTC