I reviewed the final auth patch. No changes to suggest, just a few comments.
The authentication dialog does not know which browser window opened the URL so it can't call a_Nav_reload(). Instead I implemented a_Nav_reload_url().
Removed a_Nav_reload_url() and set bw as a parameter.
<facepalm/> Why didn't I think of that? :-)
There's an interesting case when the server demands authentication for a realm that we have already authenticated ourselves to. It could be that we didn't send authentication because we didn't know the path was in the realm, or it could be that the authentication we sent was wrong. This requires the code to deduce what it did last time it saw this URL and rely on what it will do the next time. It works, but it feels fragile to me. I would prefer the URL to explicitly record authentication attempts so that the code doesn't have to second-guess itself. Thoughts?
This will need debugging. Doesn't seem critical though.
I've been testing it locally and it seems to work as expected.
I implemented a full token-value list parser as per the RFC.
I'd appreciate it in smaller functions and without gotos.
OK, I'll investigate breaking it down.
If the user opens several pages in a realm in a very short time then it is conceivable that multiple authentication dialogs for the same realm could pop up
Just added a check. It doesn't solve the problem, but avoids the storm and sends a warning to stdout.
What happens if the user opens pages for different realms at almost the same time. Will the first authentication dialog suppress the other? If so then the user will have to reload the second page before they can log in.
* Does Auth_path_is_inside() need to be case sensitive?
I think so. From RFC 2616 Hypertext Transfer Protocol -- HTTP/1.1: 3.2.3 URI Comparison When comparing two URIs to decide if they match or not, a client SHOULD use a case-sensitive octet-by-octet comparison of the entire URIs, with these exceptions: None of the exceptions apply to the path component (except for the condition that "" and "/" are the same path). Since "/foo" and "/FOO" are different paths I deduce that "/foo/bar" is not inside "/FOO". Regards, Jeremy Henty