- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 25 Mar 2008 14:00:55 +0100
- 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 UTC