- From: Greg Stein <gstein@lyra.org>
- Date: Sat, 17 Feb 2001 01:36:38 -0800
- To: w3c-dist-auth@w3.org, ietf-dav-versioning@w3.org
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:24 UTC