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

From: Larry Masinter <[email-masked]>
Date: Mon, 24 Nov 2003 16:01:26 -0800

> 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, 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?).

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

> 2. If the answer to 1 is YES, then should WebDAV servers get 
> special dispensation to leave OPTIONS * unimplemented? 

I'm not in favor of giving 'WebDAV servers' special dispensation.

> 3. If the answer to 2 is NO, then should WebDAV servers be 
> exempt from showing WebDAV support in OPTIONS *?  

Yes, for the reason of the above paragraph "a server's communication
 options typically depend on the resource".

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 24 Nov 2003 17:36:20 -0700 (MST)

On Mon, 24 Nov 2003, Larry Masinter wrote:

> 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):
>

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.

---

From: Geoffrey M Clemm <[email-masked]>
Date: Tue, 25 Nov 2003 08:42:39 -0500

Larry wrote on 11/24/2003 07:01:26 PM:

> > 3. ... should WebDAV servers be 

I think Larry has identified the key point here.  We should not be
using OPTIONS to communicate resource-dependent information.  So if
the support for a method depends on what resource it
is being applied to (which it usually does), then we should not be 
marshalling
this information via "OPTIONS *", but rather by applying the query
to the appropriate resource.

Cheers,
Geoff

---

From: Scott Lawrence <[email-masked]>
Date: Tue, 25 Nov 2003 14:30:08 -0500 (EST)

> could it be used as a test for HTTP/1.1 compliance?).

Regardless of whether or not you get an error (or even which one you
get), you still get the servers claimed HTTP version in the response
line. 

I'm not sure what more that paragraph needs to say, or what's unclear
about it.

-- 
Scott Lawrence        
  http://skrb.org/scott/

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 25 Nov 2003 14:50:47 -0700 (MST)

On Tue, 25 Nov 2003, Scott Lawrence wrote:

> >    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?).
>

What confuses people is probably that the text says "to test for
compliance" rather than saying "to detect HTTP version". Since most
HTTP/1.1 implementations are not HTTP/1.1 compliant but are using
HTTP/1.1 version, the two statements are different.

HTH,

Alex.

---

From: "Lisa Dusseault" <[email-masked]>
Date: Tue, 25 Nov 2003 17:25:00 -0800

For me, the phrase "to test the capabilities of" misled me.  I assumed
this meant that any capability added to the server, such as support
for WebDAV methods even in some limited namespaces, must be advertised
in OPTIONS * as a capability.  Since this assumption isn't backed
up by implementation reality, the HTTP text could be something like:

  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.  For example, this 
  can be used to test a proxy for HTTP/1.1 support (or lack thereof).

Lisa

> -----Original Message-----
> From: Alex Rousskov [mailto:[email-masked]] 
> Sent: Tuesday, November 25, 2003 1:51 PM
> To: Scott Lawrence
> Cc: Larry Masinter; 'Lisa Dusseault'; 'Webdav WG'; [email-masked]
> Subject: Re: OPTIONS *
> 
>

---

From: Jim Gettys <[email-masked]>
Date: Wed, 26 Nov 2003 10:51:46 -0500 (EST)

Are people happy with Lisa's suggested solution?  There has been
no comment to date.  Essentially, she suggests deleting the words
"it does nothing beyond allowing the client to test the capabilities of
the server" from the specification.

I'd like to get a draft issued.  Though I've tried for perfection
on my first try, my experience is it is likely that at least one 
more draft will have to be done before full standard, as,
at a minimum, the chances of getting all the changes decreed by
IESG process changes right on the first try seems unlikely to me.
                           - Jim

-- 
Jim Gettys <[email-masked]>
HP Labs, Cambridge Research Laboratory

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 26 Nov 2003 09:59:30 -0700 (MST)

On Wed, 26 Nov 2003, Jim Gettys wrote:

> Are people happy with Lisa's suggested solution?

I would replace "test a proxy for HTTP/1.1 support (or lack thereof)"
with a more well-defined "test a proxy for OPTIONS method support (or
lack thereof)".

Alex.