Re: OPTIONS *

Alex Rousskov wrote:
> On Mon, 24 Nov 2003, Julian Reschke wrote:
> 
> 
>>I'd like to see a clarification about what clients can expect upon
>>OPTIONS *. In particular, can they expect to find out about *any*
>>method name supported on that server?
> 
> 
> Support for OPTIONS is optional so client should not rely on that
> mechanism exclusively. That is, they should expect "405 Method Not
> Allowed" or "501 Not Implemented" response, among other things.

OK, that's clear. I was thinking about the case where OPTIONS is 
supported and implemented...

> Even if OPTIONS method is supported, client cannot expect a list of
> supported optional method names in response to OPTIONS * (in general)
> because supported optional methods may depend on the request URI. Here
> is a quote from RFC 2616, it may also clarify why Java API does not
> propagate * requests:
> 
>    If the Request-URI is an asterisk ("*"), the OPTIONS request is
>    intended to apply to the server in general rather than to a
>    specific resource. Since a server's communication options typically

I think it would be nice if the spec would clarify what "supported in 
general" means... Specifically for the "Allow" header: does it mean

- the methods listed in the Allow header are supported by all resources?
- methods not listed in the Allow header aren't supported by any resource?
- something else...?

>    depend on the resource, the "*" request is only useful as a "ping"
>    or "no-op" type of method; it does nothing beyond allowing the
>    client to test the capabilities of the server. For example, this
>    can be used to test a proxy for HTTP/1.1 compliance (or lack
>    thereof).
>    ...
>    A 200 response SHOULD include any header fields that indicate
>    optional features implemented by the server and applicable to that
>    resource
> 
> HTH,
> 
> Alex.
> 
> P.S. The "can be used to test a proxy for HTTP/1.1 compliance" phrase
>      above probably meant to say "can be used to detect HTTP version
>      of a proxy" since one cannot really test for compliance using an
>      optional method.

To me it seems that "OPTIONS *" is effectively useless except for the 
thing above -- testing compliance to a specific HTTP version. I think a 
spec revision should just state that.

Julian


-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Monday, 24 November 2003 17:26:48 UTC