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

Re: i24: Requiring Allow in 405 responses

From: Henrik Nordstrom <henrik@henriknordstrom.net>
Date: Thu, 13 Mar 2008 22:43:20 +0100
To: Julian Reschke <julian.reschke@gmx.de>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <1205444600.10356.18.camel@HenrikLaptop>

On Wed, 2008-03-12 at 13:14 +0100, Julian Reschke wrote:

> here's my proposal:
> 
> Change
> 
> "This field cannot prevent a client from trying other methods. However, 
> the indications given by the Allow header field value SHOULD be 
> followed. The actual set of allowed methods is defined by the origin 
> server at the time of each request."
> 
> to
> 
> "This field cannot prevent a client from trying other methods. The 
> actual set of allowed methods is defined by the origin server at the 
> time of each request, and may not necessarily include all (or any) 
> methods that the server would actually allow in a request if presented."


> This relaxes the server requirement (reflecting reality), and 
> accordingly removes the requirement for clients to trust the information.

With this we could just as well deprecate Allow completely as there is
no longer any defined use of the header.

I am still of the opinion that obeying what Allow says should be a
SHOULD level requirement on the client, and consequently a SHOULD or
MUST level requirement on the server to provide meaningful information.

It's not very important if a 405 includes Allow or not however, but your
proposed change is outside of 405 processing and applies to the
processing of any response. I certainly don't object to making Allow a
SHOULD (or maybe even MAY) requirement in 405 instead of a MUST. But it
should be a SHOULD level requirement in OPTIONS and the clients use of
methods.

Regards
Henrik
Received on Thursday, 13 March 2008 21:44:40 GMT

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