W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2001

RE: OPTIONS

From: Kevin Wiggen <wiggs@wiggenout.com>
Date: Thu, 1 Mar 2001 10:53:10 -0800
To: "Jason Crawford" <ccjason@us.ibm.com>, <w3c-dist-auth@w3.org>, <ietf-dav-versioning@w3.org>
Message-ID: <ONEOJMKKAIDAGPLOPJEDCEMACMAA.wiggs@wiggenout.com>

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:55 GMT