W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2003

RE: OPTIONS * (Was: RE: Comments on draft-dusseault-http-patch-00)

From: Alex Rousskov <rousskov@measurement-factory.com>
Date: Mon, 24 Nov 2003 17:36:20 -0700 (MST)
To: Larry Masinter <LMM@acm.org>
Cc: "'Lisa Dusseault'" <lisa@xythos.com>, "'Webdav WG'" <w3c-dist-auth@w3c.org>, ietf-http-wg@w3.org
Message-ID: <Pine.BSF.4.53.0311241712460.46155@measurement-factory.com>


On Mon, 24 Nov 2003, Larry Masinter wrote:

> > 1. Does HTTP/1.1 require support for OPTIONS *?  Would a HTTP
> > server that considered OPTIONS * to be a "bad request" be a
> > compliant HTTP/1.1 server?
>
> I think the wording in RFC 2616 is unclear about requiring that
> servers implement OPTIONS *. There's no explicit language to that
> effect,

Support for all methods but HEAD and GET is optional. Thus, support
for OPTIONS is optional. The explicit requirement is in section 5.1.1
"Method" of RFC 2616:

   The methods GET and HEAD MUST be supported by all general-purpose
   servers. All other methods are OPTIONAL; however, if the above
   methods are implemented, they MUST be implemented with the same
   semantics as those specified in section 9.

A server that considered OPTIONS to be a "bad request" can be a
compliant HTTP/1.1 server.

> but it does say (9.2 para 4):
>
>    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 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).
>
> So there seems to be some assumption that HTTP/1.1 compliance
> has something to do with implementing OPTIONS (otherwise how
> could it be used as a test for HTTP/1.1 compliance?).

The RFC is not being clear or precise in the "compliance" example you
quoted. Using OPTIONS, one can only test whether the agent claims to
be compliant (i.e., uses version HTTP/1.1 in response). I bet that is
the intent of the above example in the RFC.

Being optional, OPTIONS method has little practical value when it
comes to testing formal compliance.

> For a response, '501 Not Implemented' seems better than '400 Bad
> Request'.

Neither is accurate (because there is no error on the server side and
the syntax is correct from client point of view). I agree that 501 Not
Implemented is better. Many implementations respond with 400 Bad
Request if they care to respond to unknown request methods at all.

HTH,

Alex.

P.S. This came to me via ietf-http-wg; I am not on the Webdav WG list.
Received on Monday, 24 November 2003 19:40:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:49:25 GMT