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

> 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