W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1997

Re: Head response Transfer-Encoding: chunked?

From: <rlgray@raleigh.ibm.com>
Date: Thu, 18 Sep 1997 10:12:04 EST
Message-Id: <199709181412.KAA30502@rtpmail03.raleigh.ibm.com>
To: HTTP Working Group <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/4446
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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:21 UTC