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

Re: Users with different access rights in HTTP Authentication

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 23 Feb 2009 14:25:52 +0100
Message-ID: <49A2A3E0.2020507@gmx.de>
To: HTTP Working Group <ietf-http-wg@w3.org>
CC: Martin Atkins <mart@degeneration.co.uk>
...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". -- 

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.

Best regards, Julian
Received on Monday, 23 February 2009 13:26:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:48 UTC