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

From: Julian Reschke <[email-masked]>
Date: Mon, 19 Jul 2010 14:38:14 +0200

On 08.04.2009 14:52, Julian Reschke wrote:
> Mark Nottingham wrote:
>> Is this just a matter of s/allowed/supported/ in the definition of 405?
>
> Yes.
>
> That would make the definition of 405 consistent with the definition of
> the Allow header, which currently says:
>
> "The response-header field "Allow" lists the set of methods advertised
> as supported by the resource identified by the request-target. The
> purpose of this field is strictly to inform the recipient of valid
> methods associated with the resource. An Allow header field MUST be
> present in a 405 (Method Not Allowed) response." --
> <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-06.html#rfc.section.9.1>
>
>
> That would still leave the reason phrase and the *name* of the "Allow"
> header confusing, but we'll probably have to live with that.
>
> BR, Julian

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.

Best regards, Julian

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 19 Jul 2010 12:06:35 -0700

On Jul 19, 2010, at 5:38 AM, Julian Reschke 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).

....Roy

---

From: Julian Reschke <[email-masked]>
Date: Mon, 19 Jul 2010 22:13:47 +0200

On 19.07.2010 21:06, Roy T. Fielding wrote:
> ...
>> Proposed patch:<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/146/>
>>
> ...

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.

Best regards, Julian

---

From: "William A. Rowe Jr." <[email-masked]>
Date: Mon, 19 Jul 2010 15:24:58 -0500

On 7/19/2010 3:13 PM, Julian Reschke 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.
>>

What about framing this in terms of Method Not Applicable (which might be
unsupported, unimplemented, or simply nonsensical in the context of this
specific resource), which covers just about everything?

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 19 Jul 2010 23:13:04 +0200

> specific resource), which covers just about everything?

or also "not acceptable" ?

Just my few cents,
Willy

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 19 Jul 2010 22:31:25 -0700

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

> 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

---

From: Julian Reschke <[email-masked]>
Date: Wed, 21 Jul 2010 13:46:38 +0200

> specific resource), which covers just about everything?

+1

 > or also "not acceptable" ?

That would create confusion with the Accept header and status code 406.

 > lead to such a status.  Although, we might want both in some cases.

OK, so:

401 -> you can't do this because you haven't authenticated

403 -> this is forbidden for you, but authenticating as somebody else 
may help

405 -> this method is not allowed/supported/applicable for this resource

The use case you mentioned is interesting and came up before: what's a 
good way to signal to non-authenticated users that authenticating might 
give access to more operations? "Vary: Authorization" comes to mind. But 
that still would require the "public" server to know about the 
"authoring" server, in which case it might be possible to properly 
return information about method support...

Best regards, Julian

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 21 Jul 2010 14:43:11 +0200

On Wed, Jul 21, 2010 at 01:46:38PM +0200, Julian Reschke wrote:
(...)
> That would create confusion with the Accept header and status code 406.

Good point! Let's forget this one then.

(...)
> return information about method support...

Anyway, it still leaves open the expected behaviour on the client. What
should a client do when facing such a response which indicates that
(re-)authenticating as a different user *may* help satisfy the condition ?

Regards,
Willy

---

From: Julian Reschke <[email-masked]>
Date: Wed, 21 Jul 2010 15:00:46 +0200

> (re-)authenticating as a different user *may* help satisfy the condition ?

The client can at least display a meaningful message ("you are not 
allowed to edit this resource" as opposed to "this resource is not 
editable").

For non-interactive clients (think remoting access to a CMS over HTTP), 
it may effect the type of error message sent up to the caller.

Best regards, Julian

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 21 Jul 2010 15:46:08 -0700

> 401 -> you can't do this because you haven't authenticated

or the credentials are invalid.  Try again only if you can change
the credentials (user login or re-login).

> 403 -> this is forbidden for you, but authenticating as somebody else may help

yep, though forbidden can be broken down into cases:

   a) user agent sent no credentials
       if authentication might help,
          server should respond 401,
       otherwise 403

   b) user agent sent credentials that are invalid or expired
       server should send 401

   c) user agent sent valid credentials but doesn't have access
       server should send 403

> 405 -> this method is not allowed/supported/applicable for this resource

The method you just tried is not allowed for this resource.

   a) user agent sent no credentials
       if authentication might help,
          server should respond 401,
       otherwise 405

   b) user agent sent credentials that are invalid or expired
       server should send 401

   c) user agent sent valid credentials but isn't allowed
       server should send 405

> The use case you mentioned is interesting and came up before: what's a good way to signal to non-authenticated users that authenticating might give access to more operations? "Vary: Authorization" comes to mind. But that still would require the "public" server to know about the "authoring" server, in which case it might be possible to properly return information about method support...

Generally speaking, security folks prefer not to tell clients
about the ways to get in if they are supposed to know that
already.  For example, in role-based access control it is
typical to hide all operations that are not available to the
user, even though the same user can simply change their login
to see them.  The assumption is that there should be other
(application driven) hints that will tell them when to change
their user settings.

Note that this is designed for follow-your-nose (REST-based)
applications.  It doesn't work as well for applications that
think HTTP is a filesystem protocol.

....Roy