Re: OPTIONS *

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"
limitation.

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

Alex.


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