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

Mark Nottingham <mnot@mnot.net> Tue, 26 July 2011 19:45 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 4529911E8080 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 26 Jul 2011 12:45:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.638
X-Spam-Level:
X-Spam-Status: No, score=-8.638 tagged_above=-999 required=5 tests=[AWL=1.961, 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 1GbwqXDykuq2 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 26 Jul 2011 12:45:56 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 5D97F11E8088 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 26 Jul 2011 12:45:56 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1QlnZa-0001wb-9j for ietf-http-wg-dist@listhub.w3.org; Tue, 26 Jul 2011 19:45:46 +0000
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from <mnot@mnot.net>) id 1QlnZT-0001uk-Bg for ietf-http-wg@listhub.w3.org; Tue, 26 Jul 2011 19:45:39 +0000
Received: from mxout-07.mxes.net ([216.86.168.182]) by maggie.w3.org with esmtp (Exim 4.72) (envelope-from <mnot@mnot.net>) id 1QlnZR-00074y-Sp for ietf-http-wg@w3.org; Tue, 26 Jul 2011 19:45:39 +0000
Received: from dhcp-5744.meeting.ietf.org (unknown [130.129.87.68]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id A10ED22E1EB; Tue, 26 Jul 2011 15:45:16 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <4E2F1598.30101@gmx.de>
Date: Tue, 26 Jul 2011 15:45:15 -0400
Cc: Bjoern Hoehrmann <derhoermi@gmx.net>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <F49D3F37-FC08-4C8D-8565-2A2677217387@mnot.net>
References: <798C1D1A-C0C7-40DD-8993-31DB735A4961@mnot.net> <255B9BB34FB7D647A506DC292726F6E112892DE4A4@WSMSG3153V.srv.dir.telstra.com> <4E2DE5FF.7060801@gmx.de> <r92s27l82b2b7mt8ta9te03vrg0rjslpa5@hive.bjoern.hoehrmann.de> <4E2F0777.1040602@gmx.de> <4E2F1598.30101@gmx.de>
To: Julian Reschke <julian.reschke@gmx.de>
X-Mailer: Apple Mail (2.1084)
Received-SPF: pass client-ip=216.86.168.182; envelope-from=mnot@mnot.net; helo=mxout-07.mxes.net
X-W3C-Hub-Spam-Status: No, score=-1.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1QlnZR-00074y-Sp fe609385ec1e617c4e225fed7169ca27
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/F49D3F37-FC08-4C8D-8565-2A2677217387@mnot.net>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/11099
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: <E1QlnZa-0001wb-9j@frink.w3.org>
Resent-Date: Tue, 26 Jul 2011 19:45:46 +0000

Nice text; +1.

On 26/07/2011, at 3:29 PM, Julian Reschke wrote:
> Or even....:
> 
> "The credentials carried in an Authorization header field are specific to the User Agent, and therefore have the same effect on HTTP caches as the "private" Cache-Control response directive, within the scope of the
> request they appear in.
> 
> Therefore, new authentication schemes which choose not to carry credentials in the Authorization header (e.g., using a newly defined
> header) will need to explicitly disallow caching, by mandating the use of either Cache-Control request directives (e.g., "no-store") or response directives (e.g., "private")."

--
Mark Nottingham   http://www.mnot.net/