Subject: RE: OPTIONS

From: "Kevin Wiggen" <[email-masked]>
Date: Thu, 1 Mar 2001 10:53:10 -0800

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: [email-masked]
[mailto:[email-masked]]On Behalf Of Jason Crawford
Sent: Friday, February 23, 2001 8:09 PM
To: [email-masked]; [email-masked]
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.