W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2011

Ticket #294, was: 403 description clarifications

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 25 May 2011 10:07:10 +0200
Message-ID: <4DDCB8AE.8080901@gmx.de>
To: "Thomson, Martin" <Martin.Thomson@andrew.com>
CC: HTTP Working Group <ietf-http-wg@w3.org>
On 2010-09-29 03:45, Thomson, Martin wrote:
> I've had a question about 403 from an engineer here, and I think that it's a valid one.  The semantics of this header are well understood, but the actual text doesn't match that understanding.
> See: http://lists.w3.org/Archives/Public/ietf-http-wg/2010JulSep/0085.html

Indeed. We hadn't been tracking this. Sorry.

Now added as <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/294>.

> Specifically, this point:
>> 403 ->  this is forbidden for you, but authenticating as somebody else may help
> When compared with this sentence, from [1]:
>     Authorization will not help and the request SHOULD NOT be repeated.
> This sentence appears to be false [2] for the bulk of the cases where this status code is used.  If the user was authorized, then it really would help.
> I think that this is the actual intent:
>    The server understood the request, but refuses to authorize it.  Providing different user authentication credentials might be successful, but any credentials that were provided in the request are insufficient.

Sounds good to me.

> I also have a small editorial nit: The other text here about providing feedback is a separate concept and can be given a separate paragraph:
>    A server can [MAY?] instead provided a 404 (Not Found) status code to prevent clients from learning of the existence of the resource.  Alternatively, a server can provide a representation containing the reasons that the request was not fulfilled if this information can be made public.
 > ...


And yes, this sounds like a case where we want to shift from "can" to "MAY".

Best regards, Julian
Received on Wednesday, 25 May 2011 08:07:42 UTC

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