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

Well, obviously I've been reluctant to encourage implementors
to diverge from HTTP, given my assumptions that OPTIONS * is
required in HTTP/1.1.  But if that's the general consensus, 
we need to know.  

Everybody, please consider, reply, and discuss: 

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?

2. If the answer to 1 is YES, then should WebDAV servers get 
special dispensation to leave OPTIONS * unimplemented? 

3. If the answer to 2 is NO, then should WebDAV servers be 
exempt from showing WebDAV support in OPTIONS *?  

Bonus question: Can you report on any client or server HTTP or
WebDAV implementations that do, or do not, support or use 
OPTIONS *?

It may be premature to ask these questions, if the questions are
poorly formed, but at least by asking the questions we may get
feedback about how to properly ask the questions.

Implementation report: Xythos WebFile Server *does* support OPTIONS *
(and it is java servlet based, surprise surprise).  Xythos WebFile
Client does not use OPTIONS *, but it does use "OPTIONS /".

Lisa

> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@gmx.de] 
> Sent: Monday, November 24, 2003 12:51 PM
> To: Lisa Dusseault
> Cc: 'Geoffrey M Clemm'; 'Webdav WG'
> Subject: 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 16:09:11 UTC