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

Re: PROPOSAL: i24 Requiring Allow in 405 Responses

From: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 25 Mar 2008 14:00:55 +0100
Message-ID: <47E8F787.1030500@gmx.de>
To: Henrik Nordstrom <henrik@henriknordstrom.net>
CC: Mark Nottingham <mnot@mnot.net>, John Kemp <john@jkemp.net>, Brian Smith <brian@briansmith.org>, 'Stefan Eissing' <stefan.eissing@greenbytes.de>, 'HTTP Working Group' <ietf-http-wg@w3.org>

Henrik Nordstrom wrote:
> ...
> 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
> ...

I don't think so. If the authorized principal lacks permissions, the 
right response is 403 (Forbidden) or 404 (Not found, if the server 
doesn't want to reveal whether the resource exists). I don't see why it 
would ever be 405, except if the author of the server didn't understand 
the difference between 403 and 405 (and I think this is something where 
our spec could be clearer).

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

Works for me. Would we still remove the SHOULD-level requirement for the 
client?

BR, Julian
Received on Tuesday, 25 March 2008 13:01:53 GMT

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