- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 25 Nov 2003 19:22:13 +0100
- To: Alex Rousskov <rousskov@measurement-factory.com>
- Cc: Jeffrey Mogul <Jeff.Mogul@hp.com>, ietf-http-wg@w3.org, w3c-dist-auth@w3c.org
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
Received on Tuesday, 25 November 2003 13:22:29 UTC