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