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

Re: WGLC #348: Realms and scope

From: David Morris <dwm@xpasc.com>
Date: Mon, 4 Jun 2012 17:16:25 -0700 (PDT)
To: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <alpine.LRH.2.01.1206041700000.22684@egate.xpasc.com>

On Thu, 31 May 2012, Julian Reschke wrote:

> On 2012-05-31 16:57, David Morris wrote:
> > 
> > 
> > On Thu, 31 May 2012, Julian Reschke wrote:
> > 
> > > 
> > > Yes, but the realm value doesn't tell the client what part of the URI
> > > space
> > > the credentials are for.
> > > 
> > > So if you basic-authenticate to http://example.com/a successfully, the
> > > client
> > > may send the same credentials to http:://example.com/b, although it's a
> > > separate protection space.
> > 
> > But only if a http://example.com/b resource sends the realm in a
> > challenge? If my memory is correct, then this is under the control
> > of the server operator (HTTP response header filtering).
> Yes, but clients *do* send credentials in requests without having received a
> previous challenge. (Otherwise HTTP auth would require one additional round
> trip per request)

This took a few days to set up a careful test case. I don't have the time
or resources to test every client, so I can't refute the claim that some
clients send the authorization header for a part of the hosts content
which it doesn't apply to, but I've tested:

IE6, IE7, IE8 and Safari (5.1.5 on MacOS 10.7). None of these clients
sent sent the authorization header contrary to my assertion above.

Any wording in the RFC should make it clear that sending the
credentials for the parent of 'a' or for 'b' is incorrect but
may happen with broken clients.

I created the following structure on my test apache server:

a: /authab/index.html
b: /authab/a/index.html ... configured to require credentials
c: /authab/b/index.html

This each was a simple html page with links to the other two pages
and a javascript onClick handler which added a unique query string
to each request to avoid browser caching.

With tcpdump on the server to capture all port 80 traffic.
I entered url a: in each browser's address box. Navigated to c: and
from there to b: and then back to a: and finally back to c:

In each case, the browser requested credentials on the first request
for b:.

I then examined the resulting tcpdump file and confirmed that the
authorization header was not ever included on requests for a: or c:.

I'm willing to share my server with anyone who would like to test
with other clients, but I don't want the name posted on this
mailing list. Send me a private email for the info.
Received on Tuesday, 5 June 2012 00:16:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:00 UTC