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


From: Scott Lawrence <lawrence@agranat.com>
Date: Tue, 22 Jul 1997 17:36:41 -0400
Message-Id: <199707222136.RAA21238@devnix.agranat.com>
To: Josh Cohen <josh@netscape.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/3857

>>>>> "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

  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

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