Subject: RE: OPTIONS

From: "Jason Crawford" <[email-masked]>
Date: Fri, 16 Feb 2001 21:59:51 -0500

See Kevin's note below.

Does anyone have a client that depends on individual resource (including
null resources) to return different values for the OPTIONS method?

Does anyone have a client that has *any* expectations for what the OPTIONS
method returns that might be URI specific or that alternately assumes that
what is true for one resource is true for some others?

Does anyone have a server that would be unduly burdened by needing to
return URI specific results to OPTIONS requests?

I'll modify the spec accordingly, but I need people to speak up if they
would be negatively impacted if the spec took any particular stance on
this.   (If your answer to this is that you don't use OPTIONS, then just
reply to me directly and I'll sumarize for later.)

Thanks,

J.

"Kevin Wiggen" <[email-masked]> (by way of "Ralph R. Swick"
<[email-masked]>)@w3.org on 02/15/2001 12:49:18 AM

Sent by:  [email-masked]

To:   [email-masked]
cc:
Subject:  RE: OPTIONS

[freed from spam trap -rrs]

 Date: Wed, 14 Feb 2001 21:51:47 -0500 (EST)
 From: "Kevin Wiggen" <[email-masked]>
 To: "John Stracke" <[email-masked]>
 Cc: <[email-masked]>, <[email-masked]>
 Message-ID: <[email-masked]>
 Subject: [Moderator Action] RE: OPTIONS

The real question on OPTIONS is now, should a server be sending back a
different OPTIONS answer per resource.  In other words, does a server look
at the resource that has been requested and answer appropriately.  I am
CCing the DeltaV group as I have been told this is exactly what they are
proposing.

Thus an "intelligent" options request could look that a resource is not a
directory and thus return:
Allow: GET, HEAD, POST, OPTIONS, TRACE, PROPFIND, COPY, SEARCH, PROPPATCH,
LOCK, UNLOCK, PUT, DELELTE, MOVE

notice no MKCOL

If we are going to make OPTIONS useful to all clients, 2518 should define
it
a MUST for a server to return an intelligent OPTIONS response, otherwise a
client will never be able to depend on the information.

Some Apache Examples:
OPTIONS on any resource (existent or not) on Apache returns a 200 with a
Allow: GET, HEAD, OPTIONS, TRACE

Thus one could argue that following suit, a Webdav server for any resource
(existent or not) could respond: Allow: GET, HEAD, POST, OPTIONS, TRACE,
PROPFIND, COPY, SEARCH, PROPPATCH, LOCK, UNLOCK, MKCOL, PUT, DELETE, MOVE

Should Webdav 2518 state that a server MUST not do the above but
intelligently respond to an OPTIONS request?

If servers are then required to respond intelligently, what does that mean?
Does an OPTIONS to a non-existent resource without a parent simply return:
Allow:  OPTIONS

Kevin

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of John Stracke
Sent: Wednesday, February 14, 2001 8:00 AM
To: [email-masked]
Subject: Re: OPTIONS

Kevin Wiggen wrote:

> 1)  /foo is a directory with no contents.
>     OPTIONS to /foo returns a 200 with the appropriate headers
>     OPTIONS to /foo/bar returns??  200 or 404??
>     OPTIONS to /foo/bar/fee returns a 404

[...]

> Since OPTIONS
> in 2068

(Side note: you want 2616, which obsoletes 2068.)

> states "the OPTIONS request applies only to the options that are
> available when communicating with that resource."  Thus to get a 200
> response a resource must exist!!!

Well, let's see.  Consider PUT, for example; obviously, you can PUT to a
resource which does not exist (in the sense that GET would return 404).
Therefore, it is useful for OPTIONS to be able to tell you that PUT is
allowed
on that resource.

<tries stuff>...OK, let's see.  Running against Apache, if I do OPTIONS
against
a non-existent resource (in a non-existent directory), I get a 200, with
the
expected data.  GET against the same resource returns 404; SMURF against
that
resource returns 405.

To me, this seems reasonable.  I believe that *all* resources exist.  A
resource is an object whose methods are HTTP methods; you can issue an HTTP
method against any Request-URI in the server's namespace; the server will
respond.  By definition, the response is the result of that object's
method.
Therefore, there is an object named by that Request-URI.  Note that 2616,
section 10.4.5, defines 404 as meaning, "The server has not found anything
matching the Request-URI".  This is *not* the same as saying that the
specified
resource does not exist.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |"Call me a Nervous Nellie, but I am concerned|
[email-masked]|about the sale of nuclear arms in my general |
|                |neighborhood." -- Dave Barry                 |
\==============================================================/

---

From: "Lisa Dusseault" <[email-masked]>
Date: Fri, 16 Feb 2001 20:50:24 -0800

The versioning draft specifies extremely case-by-case response to
OPTIONS.  I think the OPTIONS response in DeltaV can even vary depending
on the state of a resource at one point in time vs. another.

E.g. if a resource can be turned into a "version-controlled resource",
then OPTIONS should show the VERSION-CONTROL method, to indicate that it
can be converted.

Obviously that kind of design presupposes that OPTIONS depends on
precisely what resource is named in the URL.

lisa

> [mailto:[email-masked]]On Behalf Of Jason Crawford
> Sent: Friday, February 16, 2001 7:00 PM
> To: [email-masked]
> Subject: RE: OPTIONS
>
>
>
>
>
> See Kevin's note below.
>

---

From: Greg Stein <[email-masked]>
Date: Sat, 17 Feb 2001 01:36:38 -0800

mod_dav returns different values for the OPTIONS request based on the
resource identified. (so no, I won't be "unduly burdened" :-)

I don't envision changing that, as I believe the "OPTIONS means server
options" concept (as stated before on the DeltaV list) is bogus. OPTIONS is
sent to a particular resource. Use OPTIONS * to get server information.

[ this has come up on DeltaV before: I say OPTIONS ought to take a Depth:
  header; the rebuttal was that it didn't make sense since OPTIONS referred
  to server capabilities. phphtt. no. ]

The SVN client expects information on a per-resource basis. I don't want to
know if the server has SVN capabilities; I want to know if *that* resource
is under SVN control. It is silly to take any other position.

Just go read S9.2 of RFC 2616: "... request for information ... on the
request/response chain identified by the Request-URI." and "If the
Request-URI is not an asterisk, ... applies only ... when communicating with
that resource."

Cheers,
-g

p.s. note that, in the example below, Apache doesn't handle OPTIONS well at
     all. I consider it a problem with Apache's *default* handling of
     OPTIONS. mod_dav takes particular care to return the correct
     information for resources under its control. I plan to fix the
     defaulting handling in Apache 2.0.

-- 
Greg Stein, http://www.lyra.org/

---

From: "Jim Whitehead" <[email-masked]>
Date: Sat, 17 Feb 2001 12:27:25 -0800

> Request-URI is not an asterisk, ... applies only ... when

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.

Note that this doesn't necessarily mean that a server must perform a query
for each OPTIONS request -- you could, for example, have OPTIONS code that
handles a portion of the namespace.  DeltaV could also add some constraints
as well, such as, if you support VERSION-CONTROL at one level of a namespace
hierarchy, all sub-collections also must support VERSION-CONTROL.  So, this
would allow clients to avoid sending some kinds of OPTIONS requests, if
efficiency is a concern.

- Jim