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

RE: OPTIONS *

From: Lisa Dusseault <lisa@xythos.com>
Date: Tue, 25 Nov 2003 17:25:00 -0800
To: "'Alex Rousskov'" <rousskov@measurement-factory.com>, "'Scott Lawrence'" <scott@skrb.org>
Cc: "'Larry Masinter'" <LMM@acm.org>, "'Webdav WG'" <w3c-dist-auth@w3c.org>, <ietf-http-wg@w3.org>
Message-ID: <009301c3b3bc$1cbd7df0$75c990c6@lisalap>

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:rousskov@measurement-factory.com] 
> Sent: Tuesday, November 25, 2003 1:51 PM
> To: Scott Lawrence
> Cc: Larry Masinter; 'Lisa Dusseault'; 'Webdav WG'; ietf-http-wg@w3.org
> Subject: Re: OPTIONS *
> 
> 
> On Tue, 25 Nov 2003, Scott Lawrence wrote:
> 
> > >    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?).
> >
> > 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.
> 
> 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.
> 
> 
Received on Tuesday, 25 November 2003 20:34:50 GMT

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