Re: Issue 146, was: Users with different access rights in HTTP Authentication

On Jul 19, 2010, at 1:13 PM, Julian Reschke wrote:

> On 19.07.2010 21:06, Roy T. Fielding wrote:
>> ...
>>> Proposed patch:<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/146/>
>>> 
>>> This makes the default reason phrase for 405 "Method Not Supported", and also replaces "allowed" by "supported" in the context of 405/Allow.
>> 
>> I don't believe that makes any sense.  Why the methods are allowed
>> (or others disallowed) is none of the client's business.  It certainly
>> has nothing to do with "support" (as in implemented).
>> ...
> 
> OK, then we may need a different term. "Allow" has caused people to think it has to do with access rights, thus confusing 405 with 403.

I know this can be confusing, but there is no distinction in terms
of what is going on at the server. The distinction is only in what
the server wants the client to do next.  The Allow header field may
differ based on access rights.  For example, requests can be routed
beyond the origin/gateway based on anything in the request, so a user
agent sending authenticated credentials may be talking to an entirely
different system (e.g., CQ5) than another user agent that has not
yet authenticated.  It would not be surprising that an authenticated
user is informed about more allowed methods than a non-authenticaed
user.  However, we would expect a non-authenticated user to receive
a 401 response instead of 405 if that is the case, since what the
server wants the client to do next is authenticate.

I think there is a lot of room for improvement in the way many of
the status codes are described.  We should be emphasizing what the
server is trying to communicate, rather than what conditions might
lead to such a status.  Although, we might want both in some cases.

....Roy

Received on Tuesday, 20 July 2010 05:31:54 UTC