Re: Users with different access rights in HTTP Authentication

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

Received on Wednesday, 8 April 2009 06:43:35 UTC