Browser not sending `Authorization` header set on deep url to root url

Question

When I ask user for HTTP Basic Auth at some URL, browser sends Authorization header only for this and some other URLs.

Testcase script written in PHP: http://testauth.veadev.tk/

There are three URLs to ask for credentials (you can use any random). Logout link (drops current credential after pressing "Cancel" button in browser auth form, not working in IE). Links to root URL and some test deeper URLs.

Questions:

1. Why browser not sending Authorization header at / URL if HTTP/1.0 401 Unauthorized was sent at /system/dev? To repeat: open clean http://testauth.veadev.tk/, click Auth2, enter any credentials, you'll be forwarded to / after that. You'll see Auth: null which means no credentials header was sent by browser.

2. Why does browser send Authorization header at / if HTTP/1.0 401 Unauthorized was sent at /dev? To repeat: open clean http://testauth.veadev.tk/, click Auth1, enter any credentials, you'll be forwarded to / after that. You'll see something like Auth: string 'Basic dHQ6dHQ=' (length=14) which means credentials header was sent by browser.

3. If you repeat first case and then click Auth1 you'll have credentials at Root and all other pages. Why?

4. If you click Auth3 (/some/deep/and/long/url) and you'll have credentials at Page3 (/some/deep/and/long/3) and nowhere else. Why?

To clear credential state between tests either restart your browser or click Logout, Cancel in Auth form and Root to return back (Firefox, Google Chrome).

What are the rules of sending Authorization header?

Answer 1

RFC 2617, section 2 states:

A client SHOULD assume that all paths at or deeper than the depth of the last symbolic element in the path field of the Request-URI also are within the protection space specified by the Basic realm value of the current challenge. A client MAY preemptively send the corresponding Authorization header with requests for resources in that space without receipt of another challenge from the server.

If you are using Digest Challenge, section 3.2 states that you may specify a domain in the WWW-Authenticate header to indicate what the protection space will be. I would try setting that to something like domain=/. I am not sure if this will work with Basic authorization, but it wouldn't hurt to try it; if not, Digest authorization is not much more difficult to work with and is a bit more secure.