W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2003

RE: OPTIONS * (Was: RE: Comments on draft-dusseault-http-patch-00)

From: Larry Masinter <LMM@acm.org>
Date: Mon, 24 Nov 2003 16:01:26 -0800
To: "'Lisa Dusseault'" <lisa@xythos.com>, "'Webdav WG'" <w3c-dist-auth@w3c.org>
Cc: ietf-http-wg@w3c.org
Message-id: <009f01c3b2e7$4577e260$c3432099@MasinterT40>

> 1. Does HTTP/1.1 require support for OPTIONS *?  Would a HTTP
> server that considered OPTIONS * to be a "bad request" be a 
> compliant HTTP/1.1 server?

I think the wording in RFC 2616 is unclear about requiring
that servers implement OPTIONS *. There's no explicit
language to that effect, but it does say (9.2 para 4):

   If the Request-URI is an asterisk ("*"), the OPTIONS request is
   intended to apply to the server in general rather than to a specific
   resource. Since a server's communication options typically depend on
   the resource, the "*" request is only useful as a "ping" or "no-op"
   type of method; it does nothing beyond allowing the client to test
   the capabilities of the server. For example, this can be used to test
   a proxy for HTTP/1.1 compliance (or lack thereof).

So there seems to be some assumption that HTTP/1.1 compliance
has something to do with implementing OPTIONS (otherwise how
could it be used as a test for HTTP/1.1 compliance?).

For a response, '501 Not Implemented' seems better than
'400 Bad Request'.

> 2. If the answer to 1 is YES, then should WebDAV servers get 
> special dispensation to leave OPTIONS * unimplemented? 

I'm not in favor of giving 'WebDAV servers' special dispensation.

> 3. If the answer to 2 is NO, then should WebDAV servers be 
> exempt from showing WebDAV support in OPTIONS *?  

Yes, for the reason of the above paragraph "a server's communication
 options typically depend on the resource".
Received on Monday, 24 November 2003 19:02:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:24 UTC