Subject: [Bug 44] OPTIONS *

From: [email-masked]
Date: Sun, 8 Jan 2006 02:50:27 -0800

http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=44

[email-masked] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|-08                         |-10

------- Additional Comments From [email-masked]  2006-01-08 02:50 -------
Text is still present in
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-10.html#rfc.section.9.1>.

A few comments on the current status:

- Contrary to what Lisa said, it is NOT possible to implement OPTIONS * in a
situation where several web applications share the same Java web container;
there is no delegation mechanism whatsoever that would make it possible that
information from multiple servlets is collected into a single response. It seems
to me that similar reasons would make it equally hard in a system like Apache
(when it hosts more than one application).

- I haven't heard any new feedback from either the HTTP mailing list or CalDAV.

- There's no evidence (yet?) of a generic client that actually fails if a server
does not return the DAV: header upon OPTIONS.

- It's completely unclear how a generic client can make any use of that
information, unless it also includes pointers to URLs that indeed support
WebDAV. Just knowing that there may be resources on the server allowing WebDAV
doesn't seem to be useful at all.

And finally:

- This is a new requirement, compared to RFC2518, which (a) is not implemented
interoperably today, (b) is hard or impossible to implement in many situations
and (c) doesn't seem to provide any testable advantage to clients.

Therefore I think it must be removed.

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.