Re: OPTIONS Spec

>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
   entity-body.

   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.

.....Roy

editorial note: the second sentence in that middle paragraph is bogus.

Received on Saturday, 26 July 1997 21:21:10 UTC