W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2004

Re: Using OPTIONS for optional feature discovery -- advice

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 21 Apr 2004 10:45:52 +0200
Message-ID: <408634C0.3020504@gmx.de>
To: Lisa Dusseault <lisa@osafoundation.org>
Cc: ietf-http-wg@w3.org

Lisa Dusseault wrote:

> I am working on the next version of the HTTP PATCH method proposal:
> http://www.ietf.org/internet-drafts/draft-dusseault-http-patch-00.txt
> We've had some discussions amongst WebDAV people of the best way for 
> clients to discover server feature support.  In this case, the client 
> wants to discover:
>  - if the server supports PATCH at all

That's "Allow".

>  - if so, what delta or diff formats can be used on this resource.

I think we shouldn't put this into OPTIONS. It can easily be sent back 
as response to a PATCH request with missing content-type. In which case 
there wouldn't be any change at all for OPTIONS.

> For that purpose, is a new header on OPTIONS still considered to be the 
> way to go?  Can a server omit this header on responses to OPTIONS * if 
> it only supports the feature in part of its namespace?  (E.g. if a java 
> servlet supplies support for this feature only in the namespace hosted 
> by that servlet)
> Any other comments on the draft are welcome as well.

I don't see how the set of accepted content types can be ever relevant 
for the whole namespace. In practice, clients will never be able to rely 
on all resource on a server to provide the very same feature set, thus 
will have to discover that on the resource being PATCHed anyway.


<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Wednesday, 21 April 2004 04:48:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:37 UTC