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

Head response Transfer-Encoding: chunked?

From: Scott Lawrence <lawrence@agranat.com>
Date: Mon, 15 Sep 1997 18:08:46 -0400
Message-Id: <199709152208.SAA20304@devnix.agranat.com>
To: HTTP Working Group <cuckoo.hpl.hp.com@http-wg.uucp>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/4424

  In reviewing our compliance with various directives, I've come
  across a question I'd like clarified, and perhaps get that included
  in the spec.  The question is this:

    When sending a response to a HEAD request which, if it were a GET,
    would have been sent with 'Transfer-Encoding: chunked' and no
    Content-Length header, should the response include the
    'Transfer-Encoding: chunked' header field?

  The current draft has a number of seeming relevant things to say:

  In section 4.3 Message Body:

    All responses to the HEAD request method MUST NOT include a
    message-body, even though the presence of entity-header fields
    might lead one to believe they do.

  In section 4.4 Message Length:

    1.  Any response message which MUST NOT include a message-
        body (such as the 1xx, 204, and 304 responses and any
        response to a HEAD request) is always terminated by the
        first empty line after the header fields, regardless of
        the entity-header fields present in the message.

  In section 9.4 HEAD:

    The HEAD method is identical to GET except that the server
    MUST NOT return a message-body in the response. 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.

  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.

  Since Apache doesn't send the transfer-encoding for this case
  either, I can't guess if it might confuse clients (including
  proxies) if we did.

Scott Lawrence           EmWeb Embedded Server       <lawrence@agranat.com>
Agranat Systems, Inc.        Engineering            http://www.agranat.com/
Received on Tuesday, 16 September 1997 15:01:27 UTC

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