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

Re: Users with different access rights in HTTP Authentication

From: David Morris <dwm@xpasc.com>
Date: Mon, 23 Feb 2009 06:35:45 -0800 (PST)
To: Julian Reschke <julian.reschke@gmx.de>
cc: HTTP Working Group <ietf-http-wg@w3.org>, Martin Atkins <mart@degeneration.co.uk>
Message-ID: <Pine.LNX.4.64.0902230622110.17049@egate.xpasc.com>


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
Received on Monday, 23 February 2009 14:36:38 GMT

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