Matthew Albright wrote: > How about a middle ground? I was thinking maybe storing the URL of > the place that required authentication, and then preemptively sending > the authorization for every request that is "underneath" that place > in the hierarchy...
In your example of initially authenticating with http://www.foo.bar/secure/index.html, how will you handle the following case? > YES: http://www.foo.bar/secure/upload.cgi > YES: http://www.foo.bar/secure/dir/index.html > NO: http://www.foo.bar/index.html > NO: https://www.foo.bar/secure/index.html ???: http://www.foo.bar/secure/../insecure/index.html Also, would a number of URL fragments be cached if 401s are returned with the same realm? If a realm is returned with a 401 with a "simpler" path (e.g. http://www.foo.bar/), will you simply simplify the path in the cache or just add it to the cache? (I know, this is just an implementation issue and probably doesn't belong in this design stage). > One other thing to think about is nested authorization... I don't > know what apache does if you have a .htaccess file in /secure, and > then another one with a different realm in /secure/dir ... does it > require both username/password combos, or just the innermost one? > HttpClient could handle either case, I suspect, with careful coding. I believe (someone should confirm) that the browser only stores one realm associated with a host and port. If another realm is cited in a 401 response with that host and port, that new realm will overwrite the old realm. Paul -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
