RE: #78: Relationship between 401, Authorization and WWW-Authenticate

Amos Jeffries <squid3@treenet.co.nz> Tue, 26 July 2011 01:37 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 762F611E8098 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 25 Jul 2011 18:37:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.549
X-Spam-Level:
X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCkaM6yBAni4 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 25 Jul 2011 18:37:33 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id D739911E8071 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 25 Jul 2011 18:37:33 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1QlWZZ-0006N0-KV for ietf-http-wg-dist@listhub.w3.org; Tue, 26 Jul 2011 01:36:37 +0000
Received: from aji.keio.w3.org ([133.27.228.206]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from <squid3@treenet.co.nz>) id 1QlWZL-0006Kk-GX for ietf-http-wg@listhub.w3.org; Tue, 26 Jul 2011 01:36:23 +0000
Received: from [2002:3a1c:99e9:0:206:5bff:fe7c:b8a] (helo=treenet.co.nz) by aji.keio.w3.org with esmtp (Exim 4.72) (envelope-from <squid3@treenet.co.nz>) id 1QlWZH-0006J8-TB for ietf-http-wg@w3.org; Tue, 26 Jul 2011 01:36:22 +0000
Received: by treenet.co.nz (Postfix, from userid 33) id D3F36E7062; Tue, 26 Jul 2011 13:35:46 +1200 (NZST)
To: ietf-http-wg@w3.org
X-PHP-Originating-Script: 0:func.inc
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Date: Tue, 26 Jul 2011 13:35:46 +1200
From: Amos Jeffries <squid3@treenet.co.nz>
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E112894D97F2@WSMSG3153V.srv.dir.telstra.com>
References: <798C1D1A-C0C7-40DD-8993-31DB735A4961@mnot.net> <255B9BB34FB7D647A506DC292726F6E112892DE4A4@WSMSG3153V.srv.dir.telstra.com> <4E2DE5FF.7060801@gmx.de> <20110725224402.GA31941@1wt.eu> <255B9BB34FB7D647A506DC292726F6E112894D97F2@WSMSG3153V.srv.dir.telstra.com>
Message-ID: <f96796f0e72253a27fedcd88f39e91ca@treenet.co.nz>
X-Sender: squid3@treenet.co.nz
User-Agent: Roundcube Webmail/0.5.1
Received-SPF: permerror client-ip=2002:3a1c:99e9:0:206:5bff:fe7c:b8a; envelope-from=squid3@treenet.co.nz; helo=treenet.co.nz
X-W3C-Hub-Spam-Status: No, score=-1.1
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, RDNS_NONE=0.793
X-W3C-Scan-Sig: aji.keio.w3.org 1QlWZH-0006J8-TB b994caed4cfe32600d0dfc2ac966c395
X-Original-To: ietf-http-wg@w3.org
Subject: RE: #78: Relationship between 401, Authorization and WWW-Authenticate
Archived-At: <http://www.w3.org/mid/f96796f0e72253a27fedcd88f39e91ca@treenet.co.nz>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/11087
X-Loop: ietf-http-wg@w3.org
Sender: ietf-http-wg-request@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>
Resent-Message-Id: <E1QlWZZ-0006N0-KV@frink.w3.org>
Resent-Date: Tue, 26 Jul 2011 01:36:37 +0000

 On Tue, 26 Jul 2011 10:13:11 +1000, Manger, James H wrote:
>>On Mon, Jul 25, 2011 at 11:54:07PM +0200, Julian Reschke wrote:
>>> Maybe...:
>>>
>>> Use of the Authorization header to transfer credentials implies
>>> "Cache-Control: private" [ref] and thus affects cacheability of
>>> responses. Thus, definitions of new authentication schemes that do 
>>> not
>>> use "Authorization" will need to ensure that response messages do 
>>> not
>>> leak in an unintended way, for instance by specifying 
>>> "Cache-Control" or
>>> "Vary: *" [ref] explicitly.
>>>
>>> Feedback appreciated,
>
>>I can read the first sentence in two ways :
>>  - if a server or intermediary receives an Authorization header, it 
>> must
>>    assume that "Cache-Control: private" is implied
>>  - if a client wants to emit an Authorization header, it must also 
>> add
>>    a "Cache-Control: private" header
>>
>>I think the former was meant given the second sentence, though I'm 
>> not
>>100% certain. If so, maybe we should focus on the recipient of the 
>> message
>>and replace "Use of" with "Presence of" (or anything equivalent).
>>
>>The second part is clear enough however.
>
>
> The first sentence should be read a 3rd way:
>   - if an Authorization header is present in a request, the 
> corresponding
>     response MUST be treated as though it includes "Cache-Control: 
> private",
>     unless it explicitly includes a Cache-Control header

 That wording in turn implies "Cache-Control: something-new" reverts the 
 object to public access. Not a good idea IMHO to premise it on the 
 existing of the header field.
  "unless it explicitly includes Cache-Control: public" would be better 
 wording.

 AYJ

>
> draft-ietf-httpbis-p7-auth-15#section-4.1 already contains 20 lines
> of text (1 paragraph plus 3 dot points) about caching when a request
> includes an Authorization header. This shouldn't be paraphrased
> immediately after that text with the first sentence above "... 
> implies
> Cache-Control: private...". I am not sure that the 20 lines are
> totally consistent with this first sentence.
>
> Perhaps the existing 20 lines were going to be removed, to be
> replaced with a single sentence about implying "Cache-Control:
> private" by default? That sounds ok to me, as long as the first
> sentence makes it clear that "Cache-Control: private" is implied for
> the corresponding response.
>
> Alternatively, if the existing 20 lines are kept, then just add the
> 2nd sentence of the Julian's text as a new paragraph at the end of
> section 4.1 [draft-ietf-httpbis-p7-auth-15#section-4.1]:
>
>   Use of authentication schemes that do not
>   use "Authorization" will need to ensure that response messages do 
> not
>   leak in an unintended way, for instance by specifying 
> "Cache-Control" or
>   "Vary: *" [ref] explicitly.
>
> --
> James Manger