- From: Larry Masinter <LMM@acm.org>
- Date: 2003年11月24日 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: <009f01c3b2e74577ドルe260$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