Re: OPTIONS

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.

On Fri, Feb 16, 2001 at 09:59:51PM -0500, Jason Crawford wrote:
> 
> 
> 
> 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" <wiggs@wiggenout.com> (by way of "Ralph R. Swick"
> <swick@w3.org>)@w3.org on 02/15/2001 12:49:18 AM
> 
> Sent by:  ietf-dav-versioning-request@w3.org
> 
> 
> To:   ietf-dav-versioning@w3.org
> cc:
> Subject:  RE: OPTIONS
> 
> 
> 
> [freed from spam trap -rrs]
> 
>  Date: Wed, 14 Feb 2001 21:51:47 -0500 (EST)
>  From: "Kevin Wiggen" <wiggs@wiggenout.com>
>  To: "John Stracke" <francis@ecal.com>
>  Cc: <w3c-dist-auth-request@w3.org>, <ietf-dav-versioning@w3.org>
>  Message-ID: <ONEOJMKKAIDAGPLOPJEDOEFGCMAA.wiggs@wiggenout.com>
>  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: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of John Stracke
> Sent: Wednesday, February 14, 2001 8:00 AM
> To: w3c-dist-auth@w3.org
> 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|
> |francis@ecal.com|about the sale of nuclear arms in my general |
> |                |neighborhood." -- Dave Barry                 |
> \==============================================================/
> 
> 

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

Received on Saturday, 17 February 2001 04:34:25 UTC