Re: #487 Resubmission of 403

Julian Reschke <julian.reschke@gmx.de> Mon, 01 July 2013 20:10 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E47E11E823E for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 1 Jul 2013 13:10:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.863
X-Spam-Level:
X-Spam-Status: No, score=-8.863 tagged_above=-999 required=5 tests=[AWL=1.736, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D68unq3t9v2Q for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 1 Jul 2013 13:10:52 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id B3C8D11E822D for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 1 Jul 2013 13:10:52 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UtkQ7-0003Do-2T for ietf-http-wg-dist@listhub.w3.org; Mon, 01 Jul 2013 20:09:55 +0000
Resent-Date: Mon, 01 Jul 2013 20:09:55 +0000
Resent-Message-Id: <E1UtkQ7-0003Do-2T@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <julian.reschke@gmx.de>) id 1UtkQ1-0003CO-2Q for ietf-http-wg@listhub.w3.org; Mon, 01 Jul 2013 20:09:49 +0000
Received: from mout.gmx.net ([212.227.15.18]) by lisa.w3.org with esmtp (Exim 4.72) (envelope-from <julian.reschke@gmx.de>) id 1UtkPz-0006py-1w for ietf-http-wg@w3.org; Mon, 01 Jul 2013 20:09:48 +0000
Received: from mailout-de.gmx.net ([10.1.76.10]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MeNF3-1UbHmp1pN9-00QEzR for <ietf-http-wg@w3.org>; Mon, 01 Jul 2013 22:09:20 +0200
Received: (qmail invoked by alias); 01 Jul 2013 20:09:20 -0000
Received: from p5DD95EB9.dip0.t-ipconnect.de (EHLO [192.168.1.103]) [93.217.94.185] by mail.gmx.net (mp010) with SMTP; 01 Jul 2013 22:09:20 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1+F8EoNjyaF9Ba6C35OKvy/xN60f02j1Dg/e3IZfs iDirRCDAEsFvRH
Message-ID: <51D1E1EE.7020903@gmx.de>
Date: Mon, 01 Jul 2013 22:09:18 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: "Roy T. Fielding" <fielding@gbiv.com>
CC: HTTP Working Group <ietf-http-wg@w3.org>
References: <51C325AB.7000801@gmx.de> <51D05A11.6070901@gmx.de> <FA296D41-D992-47B3-957C-DA584A0A30F1@gbiv.com>
In-Reply-To: <FA296D41-D992-47B3-957C-DA584A0A30F1@gbiv.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Received-SPF: pass client-ip=212.227.15.18; envelope-from=julian.reschke@gmx.de; helo=mout.gmx.net
X-W3C-Hub-Spam-Status: No, score=-4.4
X-W3C-Hub-Spam-Report: AWL=-2.486, BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1UtkPz-0006py-1w d9eba93fe418e377f70dac74ec0b5ce3
X-Original-To: ietf-http-wg@w3.org
Subject: Re: #487 Resubmission of 403
Archived-At: <http://www.w3.org/mid/51D1E1EE.7020903@gmx.de>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/18453
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

On 2013-07-01 19:36, Roy T. Fielding wrote:
>
> 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.
 > ...

I did, and I still think it's misleading. Again:

"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."

So how does the client find out whether the credentials or something 
else caused the problem? In the first case, we say it SHOULD NOT repeat 
the request with the same credentials, in the second case we leave it 
somehow open.

Best regards, Julian