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
> 
>