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


From: Roy T. Fielding <fielding@kiwi.ics.uci.edu>
Date: Sat, 26 Jul 1997 21:03:21 -0700
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <9707262118.aa22026@paris.ics.uci.edu>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/3937
>JC>  The actual OPTIONS message is contained in the request/response
>JC>  body.
>  What about backward compatibility with RFC 2068?  Our current
>  implementation doesn't expect or send any message body with the
>  OPTIONS method:

This is more a reminder to implementers than a response.  The RFC 2068
definition of OPTIONS does allow a body in both the request and the
response -- it just doesn't define what to do with it, and then confuses
the issue by a poor example (mea culpa).

Whether or not a message body is present is defined by section 4.3:

   The rules for when a message-body is allowed in a message differ for
   requests and responses.

   The presence of a message-body in a request is signaled by the
   inclusion of a Content-Length or Transfer-Encoding header field in
   the request's message-headers. A message-body MAY be included in a
   request only when the request method (section 5.1.1) allows an

   For response messages, whether or not a message-body is included with
   a message is dependent on both the request method and the response
   status code (section 6.1.1). 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. All 1xx
   (informational), 204 (no content), and 304 (not modified) responses
   MUST NOT include a message-body. All other responses do include a
   message-body, although it may be of zero length.

It is easy to forget about checking for a message body.  I know, because
I fixed a bug in Apache 1.2.1 last week having to do with this same issue.
Failing to check is a problem because, if the connection is persistent,
the unread message body will be mistaken for the next request.


editorial note: the second sentence in that middle paragraph is bogus.
Received on Saturday, 26 July 1997 21:21:10 UTC

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