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

I'm not so sure about clients assuming "any resource under /".  Do
you have actual cases there?  For example, even though OPTIONS *
would return "LOCK, UNLOCK" in the Allow header for a WebDAV
Level 2 server, WebDAV clients don't necessarily assume that all
collections really support LOCK.  They can't, because for example
IIS 5.0 collections don't.  Other situations might arise when the 
principal-URL space doesn't support LOCK even if the regular 
resource space does.  So I think it's already well understood, that
OPTIONS * means only that the server may in some sub-namespace
support a feature.
 
I didn't mean to denigrate anybody making any points, valid or otherwise.
Perhaps I should be more clear: if this is a HTTP problem, it needs to be
brought up in the context of HTTP design (e.g.
http://ftp.ics.uci.edu/pub/ietf/http/).
I haven't heard HTTP implementors (and there are many, many) outside
of the WebDAV WG complain about OPTIONS *.
 
Whenever WebDAV defines OPTIONS headers or bodies, WebDAV needs
to define their behavior in OPTIONS * as well as OPTIONS /specific/uri.
How could we not define this, when clients use OPTIONS * and servers
support it?
 
Lisa
 

-----Original Message-----
From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] On
Behalf Of Geoffrey M Clemm
Sent: Monday, November 24, 2003 10:31 AM
To: 'Webdav WG'
Subject: Re: OPTIONS * (Was: RE: Comments on draft-dusseault-http-patch-00)



One of the problem with "OPTIONS *" is that it is easy for 
a client to misunderstand the scope of the "server" that is 
answering the request.  Commonly, a client will assume that 
it refers to "any resource under /", but this will not be 
the case when different servers are handling different 
resources under "/". 
  
So "OPTIONS *" is reasonably well defined in simple cases 
where there is one server handling the entire web site, 
but we shouldn't be defining protocols that only work for the 
simple cases. 

Note: It doesn't particularly matter if only a "few people 
on the WebDAV mailing list" make a point, if that point is 
valid.  Most people building web servers only read the 
WebDAV mailing list infrequently, if at all, and even fewer 
of them feel comfortable or have the time to post.  So we should 
make optimal use of those that are consistent readers and 
posters. 

Cheers, 
Geoff 


Lisa wrote on 11/24/2003 01:04:57 PM:

> 
> > Note that the proposed "OPTIONS *" functionality will not 
> > work anyway. 
> > Is it worth keeping the remainder?
> 
> OPTIONS * is an HTTP feature, not a WebDAV feature that we can
> keep or throw away.  It's been there for years.  I haven't seen
> much opposition to the feature, outside of a few people on the
> WebDAV mailing list.  It's got useful semantics.
> 
> It's too bad, as Julian has pointed out in the past, that the
> Java servlet design made it difficult to add stuff to OPTIONS *.
> (It's not impossible, just difficult.  I can point to existence
> proofs that it's possible, it just requires taking over the root
> namespace with a servlet application, or doing something outside
> the servlet framework.)  To me, that argues for fixes to the 
> Java servlet functionality, not dropping an HTTP feature.  If
> Microsoft "broke" OPTIONS * in its ISAPI design, the standards
> community would not be so likely to quietly drop support for it.
> 
> Lisa
> 
>