RE: OPTIONS

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

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford
> Sent: Friday, February 16, 2001 7:00 PM
> To: w3c-dist-auth@w3.org
> Subject: RE: OPTIONS
>
>
>
>
>
> 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                 |
> \==============================================================/
>
>
>

Received on Friday, 16 February 2001 23:51:29 UTC