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


From: Alex Rousskov <rousskov@measurement-factory.com>
Date: Tue, 25 Nov 2003 10:26:45 -0700 (MST)
To: Jeffrey Mogul <Jeff.Mogul@hp.com>
Cc: Julian Reschke <julian.reschke@gmx.de>, ietf-http-wg@w3.org, w3c-dist-auth@w3c.org
Message-ID: <Pine.BSF.4.53.0311251002120.97307@measurement-factory.com>

Given Jeff's comments, would it make any sense for those who need a
working OPTIONS to specify their own extension method (e.g., FEATURES)
and publish a small RFC instead of patching RFC 2616?
Draft-ietf-http-options could be a starting point. One problem would
be with proxies that do not pass extension methods on, unfortunately.
But some do not pass OPTIONS as well, so it is not such a "new"

Adding some extension header to OPTIONS, to signal new well-defined
functionality would be a similar approach that does not require an
extension method.


On Tue, 25 Nov 2003, Jeffrey Mogul wrote:

> I think there is no doubt that many or most of the authors think
> that OPTIONS is basically broken in RFC2616, so a well-designed
> rewording is probably welcome.  However, given that (1) we are not
> likely to change the version number at this stage, and (2) without
> changing the version number we cannot really expect to place new
> requirements on servers, any change that might be proposed is
> probably more likely to be of the form "clients cannot count on
> OPTIONS behavior, but here's some advice to server implementors."
> -Jeff
> P.S.: for what it is worth (not much at this point), Scott
> himself was a co-author of draft-ietf-http-options-02.txt,
> "Specification of HTTP/1.1 OPTIONS messages", back in 1997.  My
> recollection is that the Working Group rejected this approach and
> so the I-D died, but in my opinion it was the best design that was
> available.  (My opinion is biased, for reasons that might be
> obvious to anyone who reads this draft, available via Google and
> other fine search engines.)
Received on Tuesday, 25 November 2003 12:27:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:24 UTC