W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2013

Re: #487 Resubmission of 403

From: Roy T. Fielding <fielding@gbiv.com>
Date: Mon, 1 Jul 2013 10:36:22 -0700
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <FA296D41-D992-47B3-957C-DA584A0A30F1@gbiv.com>
To: Julian Reschke <julian.reschke@gmx.de>

On Jun 30, 2013, at 9:17 AM, Julian Reschke wrote:

> On 2013-06-20 17:54, Julian Reschke wrote:
>> From the ticket:
>> 
>>> See comments in linked blog post; change
>>> 
>>> "The client should not repeat the request with the same credentials."
>>> 
>>> to
>>> 
>>> "The client should not automatically repeat the request with the same
>>> credentials."
>>> 
>>> Since some flows using 403 may involve manipulating state somewhere
>>> else, then resubmitting the request.
>> 
>> ...where the blog post is:
>> <http://www.mnot.net/blog/2013/05/15/http_problem>
>> 
>> The current text is:
>> 
>> "The 403 (Forbidden) status code indicates that the server understood
>> the request but refuses to authorize it. A server that wishes to make
>> public why the request has been forbidden can describe that reason in
>> the response payload (if any).
>> 
>> If authentication credentials were provided in the request, the server
>> considers them insufficient to grant access. The client SHOULD NOT
>> repeat the request with the same credentials. The client MAY repeat the
>> request with new or different credentials. However, a request might be
>> forbidden for reasons unrelated to the credentials.
>> 
>> An origin server that wishes to "hide" the current existence of a
>> forbidden target resource MAY instead respond with a status code of 404
>> (Not Found)." --
>> <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-latest.html#status.403>
>> 
>> 
>> It seems there's a bigger problem here:
>> 
>> "If authentication credentials were provided in the request, the server
>> considers them insufficient to grant access."
>> 
>> This implies that *if* credentials have been provided, and the result is
>> 403, it's due to the credentials.

No, it does not.  Such a conclusion is not supportable by logic or
English, and certainly not in programming languages, so I see no
reason for a change here.  Read the entire paragraph.

>> ...
> 
> Here's an attempt of rewriting the second paragraph:
> 
> "Insufficient credentials can be a reason for refusing the request. In this case, the client SHOULD NOT repeat the request with the same credentials. However, a request might be forbidden for reasons unrelated to the credentials, and therefore the client has no reliable way to detect this situation."

No, that is just making a mountain out of a molehill.
403 means forbidden.  One reason for forbidding is that the
credentials provided are for a user that is forbidden.  The
correct way to state that is as written in the spec -- the
credentials are insufficient to gain access.  That does not
mean the credentials caused the 403; it means they were not
sufficient to overcome the 403.  A client is fully capable of
detecting whether it sent credentials and either using a
different set (if possible) or halting accordingly. It is
not the client's job to "detect" why the 403 is received.

....Roy
Received on Monday, 1 July 2013 17:36:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:14 UTC