Subject: Re: how to specify extension features in response to OPTIONS request

From: Greg Stein <[email-masked]>
Date: Tue, 19 Mar 2002 05:16:39 -0800

On Tue, Mar 19, 2002 at 10:58:32AM +0100, Julian Reschke wrote:
> > [mailto:[email-masked]]On Behalf Of Sohn, Matthias
>...
> > is it possible to specify extension features (that are not defined in the
> > DeltaV spec) in the response to a OPTIONS request ?
> 
> It's possible, but I would strongly recommend not to do that.
> 
> If you need a non-intrusive way to signal server extensions, use a custom
> live property.

There was some amount of consensus a while back on the DAV WG list that the
DAV: header should allow Coded-URLs in it. mod_dav took this approach, so an
OPTIONS response looks like:

HTTP/1.1 200 OK
Date: Tue, 19 Mar 2002 13:10:17 GMT
Server: Apache/1.3.19 (Unix) DAV/1.0.2
Content-Length: 0
MS-Author-Via: DAV
Allow: OPTIONS, GET, HEAD, POST, DELETE, TRACE, PROPFIND, PROPPATCH, COPY, MOVE, LOCK, UNLOCK
DAV: 1,2,<http://apache.org/dav/propset/fs/1>
Connection: close
Content-Type: text/plain

Cheers,
-g

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

---

From: "Julian Reschke" <[email-masked]>
Date: Wed, 20 Mar 2002 10:12:26 +0100

> From: Lisa Dusseault [mailto:[email-masked]]
> Sent: Wednesday, March 20, 2002 3:24 AM
> To: 'Greg Stein'; 'Julian Reschke'; 'Sohn, Matthias'
> Cc: [email-masked]; [email-masked]
> Subject: RE: how to specify extension features in response to OPTIONS
> request
>
>
> If Greg's approach is taken to avoid conflicts, then I see no
> strong reason
> to prefer live properties over OPTIONS header values in the general case.

...other that in this case this way to extend the DASL header must be
documented somewhere...?

> However, if the feature is one which relates only to some resources (e.g.
> all collections support the feature, or all resources in the
> directory foo,
> etc) then it might be helpful to advertise support for the feature only on
> those resources, using a live property as suggested.
>
> OPTIONS * still seems to be the most appropriate place to marshall
> server-wide features, with the conflict-avoidance caveats already
> mentioned.

How can this be the appropriate place if RFC2518 doesn't document how to do
that?

---

From: "Jim Whitehead" <[email-masked]>
Date: Wed, 20 Mar 2002 14:23:05 -0800

Also accidentally caught by the spam filter.

- Jim

-----Original Message-----
From: Lisa Dusseault [mailto:[email-masked]]
Sent: Tuesday, March 19, 2002 6:23 PM
To: 'Greg Stein'; 'Julian Reschke'; 'Sohn, Matthias'
Cc: [email-masked]; [email-masked]
Subject: [Moderator Action] RE: how to specify extension features in
response to OPTIONS request

> OPTIONS response looks like:

If Greg's approach is taken to avoid conflicts, then I see no strong reason
to prefer live properties over OPTIONS header values in the general case.

However, if the feature is one which relates only to some resources (e.g.
all collections support the feature, or all resources in the directory foo,
etc) then it might be helpful to advertise support for the feature only on
those resources, using a live property as suggested.

OPTIONS * still seems to be the most appropriate place to marshall
server-wide features, with the conflict-avoidance caveats already mentioned.

Lisa