RE: OPTIONS

I do not think the HTTP spec says enough, and for OPTIONS to be useful to
clients, I think we need to specify what the behavior is.

It's useful to look at a few use cases and discuss what the server should
respond.

Take for instance:

/foo is an empty directory

OPTIONS /foo
Allow: GET, HEAD, POST, OPTIONS, TRACE, PROPFIND, COPY, SEARCH
If the /foo is writeable add PROPPATCH, LOCK, UNLOCK

OPTIONS /foo/bar
Allow: OPTIONS
If /foo is writeable add MKCOL, PUT, LOCK

OPTIONS /foo/bar/fee
Allow: OPTIONS

This is one way of handling the OPTIONS, I can think of other permutations
that might make sense.  Again for this to be truly useful information to a
client, I believe we need to state what a server should respond with to a
client in each case.

Kevin


-----Original Message-----
From: w3c-dist-auth-request@w3.org
[mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford
Sent: Friday, February 23, 2001 8:09 PM
To: w3c-dist-auth@w3.org; ietf-dav-versioning@w3.org
Subject: RE: OPTIONS




<<
I concur -- it's pretty clear that OPTIONS in HTTP/1.1 is per-resource,
unless the Request-URI is "*".  It's fairly typical for Web servers to have
different capabilities in different parts of their namespace.
>>
So do we want 2518 to say anything or leave this for HTTP/1.1?  It sounds
to me that all the questions asked here about OPTIONS in the last two weeks
are probably best left to the HTTP/1.1 spec.  (I just wish that spec said
more.)

J.

Received on Thursday, 1 March 2001 13:53:53 UTC