RE: OPTIONS *

Accidentally caught by the spam filter. I have added "Jim.Gettys@hp.com" to
the accept2 filter.

- Jim

-----Original Message-----
From: Jim Gettys [mailto:Jim.Gettys@hp.com]
Sent: Wednesday, November 26, 2003 7:51 AM
To: Lisa Dusseault
Cc: 'Alex Rousskov'; 'Scott Lawrence'; 'Larry Masinter'; 'Webdav WG';
ietf-http-wg@w3.org
Subject: [Moderator Action] RE: OPTIONS *




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

On Tue, 2003-11-25 at 20:25, Lisa Dusseault wrote:
> 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.
> >
> >
--
Jim Gettys <Jim.Gettys@hp.com>
HP Labs, Cambridge Research Laboratory

Received on Monday, 1 December 2003 14:56:15 UTC