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

Lisa Dusseault wrote:

> Ahh, here's our disconnect.  My assumption is that RFC2518 *does* 
> require OPTIONS * to work, because RFC2518 requires that RFC2616
> be implemented.  It's just one of many things that are part of 
> WebDAV because they're part of HTTP/1.1.  It's my reading that support
> of OPTIONS * is required for HTTP/1.1 therefore it was already 
> required for WebDAV.  The addition to RFC2518bis was intended to
> make obvious something that I thought implementors might not notice.

Ok, let's assume HTTP *does* require this (IMHO that on the other hand 
should be clarified on the HTTP mailing list). In which case for 
RFC2518bis, it's our job to actually find out whether there's 
interoperability for this.

I just tried both Apache/mod_dav and our server. None of them supports 
it. On the other hand, I haven't seen any client failing because of 
this. Thus, if any clarification is required, then it's to say that 
clients can not rely on anything WebDAV specific being returned by 
OPTIONS *.

>>>Whenever WebDAV defines OPTIONS headers or bodies, WebDAV needs
>>>to define their behavior in OPTIONS * as well as OPTIONS 
>>
>>/specific/uri.
>>
>>Fine. So please define that WebDAV doesn't put any additional 
>>semantics 
>>on OPTIONS *.
> 
> 
> That's an interesting proposal.  How would you recommend doing that? 
> Would the Allow header be incomplete?  Would the DAV: header be 

It is with many existing implementations.

> *missing* on a response to OPTIONS *?  Would DeltaV elements like

Same.

> 'DAV:version-history-collection-set' be illegal in the OPTIONS request
> body if the Request-URI were '*'?  I fear this approach would break 

Yes. That's a known defect in DeltaV, therefore the marshalling through 
OPTIONS has been deprecated, and live properties have been added instead 
(see issues 5.5_OPTIONS_BODY and 5.5_USE_PROPERTIES on 
<http://www.webdav.org/deltav/protocol/rfc3253-issues-list.htm>).

> existing client implementations that do use OPTIONS * to detect 
> server support.

Show me one.

> It's a valid approach to say that WebDAV doesn't use, or doesn't
> need, OPTIONS *.  However, I think that approach is less consistent, 
> less compliant, and less interoperable with HTTP/1.1.  I still 
> prefer for WebDAV to make clear that OPTIONS * support is required.
> Then perhaps we'd eventually get out of our current situation of 
> servers not supporting it properly, by having them add support.

Well. Servers not supporting it right now doesn't seem to be any 
*practical* problem. Could you please elaborate?

Regards, Julian

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

Received on Monday, 24 November 2003 15:51:40 UTC