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

Re: PROPOSAL: i24 Requiring Allow in 405 Responses

From: Henrik Nordstrom <henrik@henriknordstrom.net>
Date: Thu, 20 Mar 2008 23:28:41 +0100
To: Mark Nottingham <mnot@mnot.net>
Cc: John Kemp <john@jkemp.net>, Brian Smith <brian@briansmith.org>, "'Julian Reschke'" <julian.reschke@gmx.de>, "'Stefan Eissing'" <stefan.eissing@greenbytes.de>, "'HTTP Working Group'" <ietf-http-wg@w3.org>
Message-Id: <1206052121.15894.123.camel@HenrikLaptop>

On Fri, 2008-03-21 at 08:44 +1100, Mark Nottingham wrote:

> Your suggestion clarifies when an Allow header must/should appear, but  
> does not clarify what it must contain -- although there seems to be an  
> implication that it be 'complete.'
> 
> As others and myself have pointed out before, that's not realistic.

I still haven't really got what about "lists the set of methods
supported by the resource" is unclear. A method is either supported or
it's not.

But a small suggestion is found below maybe addressing the concerns and
lining up the definition more with the intended use and emphasizing why
sending meaningful Allow headers is important.


What is currently said about the contents of Allow:

"Method"

   The list of methods allowed by a resource can be specified in an
   Allow header field (section "Allow"). The return code of the response

"OPTIONS"

   A 200 response SHOULD include any header fields that indicate
   optional features implemented by the server and applicable to that
   resource (e.g., Allow), possibly including extensions not defined by
   this specification.

"405 Method not allowed"

   [...] include an
   Allow header containing a list of valid methods for the requested
   resource.

"Allow"

      [...] lists the set of methods supported
      by the resource identified by the Request-URI. The purpose of this
      field is strictly to inform the recipient of valid methods
      associated with the resource.

[...]

      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.


My reading of the above: It's a header telling the client "These are the
methods I currently support on this resource and which you MAY use to
perform actions on this resource. I recommend you not to try to use any
other methods as I most likely do not support them and will reject any
such attempts with an appropriate error so doing so would be a waste of
both yours and my time and resources."

For security reasons the following may also be implied "Things may
change in the future if my configuration or the resource state is
changed to allow other methods or significant properties of your request
changes making you gain more access rights than you have today.", but I
am not convinced the specs really means the latter. But makes sense from
a security point of view and is commonly implemented today.  The first
(configuration & state) is kind of pointless to mention as it's a
constant fact about anything, but is what the "at the time of each
request" is about.


So here is my suggestion about resolving the contents of Accept:

Does it help to get readers more aligned if "Allow" is rewritten to
include advertised in the definition?

     [...] lists the set of methods advertised as supported ...


Regards
Henrik
Received on Thursday, 20 March 2008 22:30:49 GMT

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