New issue
Advanced search Search tips

Issue 864572 link

Starred by 1 user

Issue metadata

Status: Untriaged
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

HTTP auth blocks the cache lock.

Project Member Reported by davidben@chromium.org, Jul 17

Issue description

mmenke 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...)
 
Note that dropping everything with NTLM / negotiate seems like it may not be doable, assuming the embedder can manage the round by round authentication they need.
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. :-/
Labels: Network-Triaged

Sign in to add a comment