- From: Mark Nottingham <mnot@mnot.net>
- Date: Wed, 8 Apr 2009 16:42:54 +1000
- To: David Morris <dwm@xpasc.com>
- Cc: Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>, Martin Atkins <mart@degeneration.co.uk>
Is this just a matter of s/allowed/supported/ in the definition of 405? On 24/02/2009, at 1:35 AM, David Morris wrote: > > > On Mon, 23 Feb 2009, Julian Reschke wrote: > >> ...following up from a discussion on www-talk: >> >> Martin Atkins wrote: >>> Julian Reschke wrote: >>>>> * Return 405 Method Not Allowed, and indicate in the "Allow" >>>>> response header the methods that this particular authenticated >>>>> user is allowed to perform. (i.e. Allow: GET) >>>> The description for 405 is not very clear, but the one for >>>> "Allow" is (IMHO): >>>> "The Allow entity-header field lists the set of methods supported >>>> by the resource identified by the Request-URI." -- <http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.7 >>>> > >>>> So no, this doesn't fit. >>> So I guess the thought here is that the text says "methods >>> supported" rather than "methods allowed", which implies that it is >>> not user-sensitive. >>> If Allow is not supposed to reflect the access rights of the >>> remote user, can you suggest an alternative mechanism by which I >>> can tell the client "You can GET but you don't have access to PUT >>> or DELETE?" >>> (Currently I'm using "Allow" for this, but now that you've called >>> out that specific sentence I agree that it does not seem to be >>> intended to reflect access rights.) >>> The need is letting user-agents that retrieve the resource know >>> ahead of time that a PUT or DELETE will not be allowed so that the >>> UI can reflect this, for example by displaying a "Read-only" >>> indicator and disabling the "Save" button. >>> ... >> >> Part 2 currently says about status 405: >> >> "8.4.6 405 Method Not Allowed >> >> The method specified in the Request-Line is not allowed for the >> resource identified by the request-target. The response MUST >> include an Allow header containing a list of valid methods for the >> requested resource." >> >> Martin is not the first one to read this as "the authenticated user >> is not allowed to, but somebody else might". -- <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-05.html#rfc.section.9.4.6 >> > >> >> But this is not what the description of the related "Allow" header >> implies: >> >> "10.1 Allow >> >> The response-header field "Allow" lists the set of methods >> advertised as supported by the resource identified by the Request- >> URI..." -- <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-05.html#rfc.section.10.1 >> > >> >> ...which makes it matter of being supported by the resource in >> general. >> >> We probably should clarify this in the description of status 405. > > I don't see a reason why it matters except in the context in which > the request is issued. That context may include some form of > knowledge about who the user is. That request is NOT ALLOWED for > THAT USER. Telling user A that a request is allowed for some OTHER > USER just invites an attempt by user A to become authorized as if > they are USER B. > > I don't see any legitimate interoperability harmed by a server using > 405 to mean YOU or ALL OF YOU. > > I don't see it as a legitimate objective of the HTTP protocol to let > EVERYONE learn what YOU are allowed to do. > > And reading the two cited sections, I see no conflict. "Methods > advertised" can be contextual w.r.t. the specific user context, if > the server so chooses OR it can apply to all users. I see no > underlying reason to make a change to avoid this flexibility and I > don't see any lack of clarity which requires expanding the final > document. > > David Morris > -- Mark Nottingham http://www.mnot.net/
Received on Wednesday, 8 April 2009 06:43:35 UTC