Re: OPTIONS Spec

>>>>> "JC" == Josh Cohen <josh@netscape.com> writes:

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:

   Request:                 Response:

    OPTIONS * HTTP/1.1       HTTP/1.1 200 OK
    Host: www.agranat.com    Date: Tue, 22 Jul 1997 20:14:06 GMT
    Connection: close        Server: Agranat-EmWeb/R3_0alpha4
    User-Agent: wwwreq/1.6   Connection: close
                             Allow: HEAD, GET, POST, TRACE, OPTIONS

  Re-reading the spec, it is possible that we should have used
  'Public' rather than 'Allow' in that response.  I believe that our
  thinking was that we wanted re result to get back through a proxy,
  but I'm not sure.

  Our response is consistent with Apache:

    OPTIONS * HTTP/1.1       HTTP/1.1 200 OK
    Host: www.apache.org     Date: Tue, 22 Jul 1997 20:21:51 GMT
    Connection: close        Server: Apache/1.3-dev
    User-Agent: wwwreq/1.6   Content-Length: 0
                             Allow: GET, HEAD, OPTIONS, TRACE
                             Connection: close

  (hmm... apache doesn't list POST... perhaps it is interpeting that
  as 'OPTIONS /')

  ... but not quite what John Mallery's Common Lisp server does (it
  uses the Public header) [I folded the 'Public:' for this mail]:

    OPTIONS * HTTP/1.1       HTTP/1.1 200 OK
    Host: wilson.ai.mit.edu  Date: Tue, 22 Jul 1997 20:25:37 GMT
    Connection: close        Server: CL-HTTP/63.61 (Symbolics Common Lisp)
    User-Agent: wwwreq/1.6   Connection: CLOSE
                             Public: post, PUT, TRACE, OPTIONS,
                                     DELETE, GET, HEAD
                             Cache-Control: NO-CACHE

  ... any others out there?

  A section defining some variation on the above as the expected
  behaviour if no body is sent (no Content-Length header) would do the
  trick.  I just checked, and if there is a body, we just ignore it
  and send the response above, so I guess that a client could detect
  that a server like our current version just didn't know about this
  when it got back no body.  I can't easily run that test on those
  others...

  On another note, is it your intention that the feature-token values
  be specified as a part of whatever document defines the feature?  If
  so, we should add feature-token values to the next HTTP/1.1 for the
  optional features it specifies.

--
Scott Lawrence           EmWeb Embedded Server       <lawrence@agranat.com>
Agranat Systems, Inc.        Engineering            http://www.agranat.com/

Received on Tuesday, 22 July 1997 16:51:38 UTC