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