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

Re: Basic auth and realms

From: Bjoern Hoehrmann <derhoermi@gmx.net>
Date: Mon, 16 Jun 2008 01:59:32 +0200
To: Adrien de Croy <adrien@qbik.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <knab54hnu9874j0c5j1bp479usml1df8oh@hive.bjoern.hoehrmann.de>

* Adrien de Croy wrote:
>The description of this realm parameter is confusing.  Especially when 
>considering a proxy.  Commonly a proxy will want a realm that means 
>"everywhere".  How should one specify this?  would it be
>or what?

Section 2 for Basic notes "The realm value should be considered an
opaque string which can only be compared for equality with other
realms on that server." Meaning it does not matter which string you
use as far as the protocol is concerned.

>"The realm directive (case-insensitive) is required for all 
>authentication schemes that issue a challenge. The realm value 
>(case-sensitive), in combination with the canonical root URL (the 
>absoluteURI for the server whose abs_path is empty; see section 5.1.2 of 
>[2]) of the server being accessed, defines the protection space. "

This is talking about tuples

  { 'http://example.com', 'Realm 1' }, # Protection space 1
  { 'http://example.com', 'Realm 2' }, # Protection space 2
  { 'http://example.com', 'Realm 3' }, # Protection space 3

>Browsers seem to behave differently in regards to when they will 
>automatically re present the same proxy credentials.

The specification just says

  Similarly, when a client sends a request to a proxy, it may reuse a
  userid and password in the Proxy-Authorization header field without
  receiving another challenge from the proxy server.

So they are indeed free to differ in this regard.
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 
Received on Monday, 16 June 2008 00:00:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:46 UTC