HTTP auth blocks the cache lock. |
||
Issue descriptionmmenke and I were chatting about this. This is similar to issue #6697, but it won't be fixed by committed interstitials. 1. Open https://davidben.scripts.mit.edu/auth-test in one tab. Don't type in a password. 2. Open https://davidben.scripts.mit.edu/auth-test in another tab. The second load hangs waiting for the first to resolve, due to the cache lock. Probably what we should do is, in the cache, if we get HTTP auth or certificate exception during Start(), release the cache lock and drop everything. Start everything over from the top. (Since the reason we have a cache lock is to worry about consistency.) If we get one of those during Read() because we're doing some partial request, maybe just fail the request altogether. This shouldn't happen unless auth expires in the middle of fetching partials. (Do we hold the cache lock across Read for partials? If not, I suppose we could request auth and it'd still be fine...)
,
Jul 18
Oh hrm, good point. We wouldn't have to drop the connection, but we'd have to drop the HTTP cache headers (since those depend on state that we've stopped locking). I don't know if NTLM and friends react well to changing your mind on cache headers like that. :-/
,
Jul 25
|
||
►
Sign in to add a comment |
||
Comment 1 by mmenke@chromium.org
, Jul 17