W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2008

Re: i24: Requiring Allow in 405 responses

From: Roy T. Fielding <fielding@gbiv.com>
Date: Tue, 5 Feb 2008 10:11:57 -0800
Message-Id: <EC1E215F-30D3-4AB0-8AEE-0FD0451BE1CD@gbiv.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
To: Mark Nottingham <mnot@mnot.net>

On Feb 4, 2008, at 11:08 PM, Mark Nottingham wrote:

> My thinking was that it may be necessary to preserve the MUST on  
> the presence of the header (in case any software had been written  
> to depend upon its presence), but to loosen the implied requirement  
> that the list of headers be complete.

The likelihood of real (non-testcase) software depending on Allow
being present is nil.  I can't even remember why the MUST was added
in the first place -- it certainly isn't useful for interoperability,
since a client can't very well choose from among the methods listed
as a replacement for the method attempted.  I added it in the first
pre-WG draft of HTTP/1.0 (Nov 94) as

    405 Method Not Allowed

        o  Required metainformation:  Allow

    The method specified in the Request-Line is not allowed for the
    object identified by the URI. The server should send back an Allow
    header containing a list of valid method's as explained in Section
    7.1.

which means it dates from back in the days when HTTP was expected
to be an object remoting protocol (many more methods).  Note that
this draft also had

    The methods GET and HEAD must be supported by all conforming
    HTTP/1.0 servers. The list of methods acceptable by a specific
    object can be specified in an "Allow" Object-Header (Section 7.1).
    However, the client is always notified through the return code of
    the response whether a method is currently allowed on a specific
    URI, as this can change dynamically. The set of common methods for
    HTTP/1.0 are specified below. Although this set can be easily
    expanded, additional methods cannot be assumed to share the same
    semantics for separately extended clients and servers. In order to
    maintain compatibility, the semantic definition for extension
    methods should be registered with the HTTP registration authority
    (Section 10). Servers should return the Status-Code "501 Not
    Implemented" if the method is unknown.

Even if any software does make use of the Allow field, the result
in its absence is the same -- an error has been indicated by the
server.  That is why I think including Allow should be MAY.

....Roy
Received on Tuesday, 5 February 2008 18:11:44 GMT

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