Subject: Re: OPTIONS *

From: Julian Reschke <[email-masked]>
Date: Tue, 25 Nov 2003 19:22:13 +0100

Alex Rousskov wrote:

> Given Jeff's comments, would it make any sense for those who need a
> working OPTIONS to specify their own extension method (e.g., FEATURES)
> and publish a small RFC instead of patching RFC 2616?

Possibly, but I don't think this applies to the questions that got us here.

WebDAV uses the DAV: response header in OPTIONS, and so far this seems 
to work just fine. The only disagreement that we have (had?) is whether 
clients can rely on "OPTIONS *" returning something meaningful. I think 
it has been shown that they can't, thus RFC2518bis shouldn't add any new 
language suggesting that. In addition, we have no evidence of clients 
that actually use that.

Regarding Lisa's draft for a PATCH method, I still believe that getting 
rid of any dependencies on OPTIONS will make it easier to be 
acccepted/implemented. At the very least it shouldn't require "OPTIONS 
*" to do anything it won't actually do in practice.

> ...
> 
> Adding some extension header to OPTIONS, to signal new well-defined
> functionality would be a similar approach that does not require an
> extension method.

That's what WebDAV already does 
(<http://greenbytes.de/tech/webdav/rfc2518.html#HEADER_DAV>), and 
besides the problem with "OPTIONS *", there doesn't seem to be any 
real-world problem with it.

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: Julian Reschke <[email-masked]>
Date: Tue, 25 Nov 2003 19:29:58 +0100

Scott Lawrence wrote:

 > ...
> I agree that the best that can be done now is to document what can and
> cannot be achieved with what we have (pretty limited, but it does make
> a good no-op message; we used it that way in RFC 2817).

Agreed. So I think what we want to replace is 
<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.9.2.p.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)."

Any proposals for replacement text?

Julian