Clarify network events received for authentication attempts

[juliandescottes]

Assuming the client listens to network events, consider a basic http authentication flow where the user first performs a request and then provides credentials (either manually via the prompt, or using interception+continueWithAuth).

At the moment in Firefox the user will receive the following events:

• beforeRequestSent for original request
• responseStarted for original request
• authRequired for original request
• beforeRequestSent for authentication request
• responseStarted for authentication request
• responseCompleted for original request
• responseCompleted for authentication request

So we are getting two sets of network events, one for the original request and one for the authentication request. For now in Firefox those 2 requests have the exact same id.

Looking at the fetch spec, the authentication request is triggered from:

Set response to the result of running HTTP-network-or-cache fetch given fetchParams and true.

(step 14.4 of https://fetch.spec.whatwg.org/#http-network-or-cache-fetch)

So spec wise we are actually reusing the same request object, and we would get beforeRequestSent/responseStarted again for the same request id as the original request. And still according to the spec we should only get a single responseCompleted event once the authentication is done.

Are we happy with that model, where we will get N beforeRequestSent/responseStarted/authRequired events for a single responseCompleted and a single request id? Or do we want to update the spec to have unique request ids and/or individual responseCompleted events.

@OrKoN Do you know how Chrome behaves in this scenario and which events it will emit?

[annevk]

I was wondering about this in the context of redirects as well, where it seems like the same thing will happen?

And this might also happen with CORS preflights. I'm not sure if that scenario is tested?

[OrKoN]

Chrome currently handles the events in the following way (when the authRequired is not subscribed to, and dialog is shown to the user):

• network.beforeRequestSent for the original
• network.responseStarted for the original
• network.responseCompleted for the original
• network.fetchError for the original
• network.beforeRequestSent for the auth request
• network.responseStarted for the auth request
• network.responseCompleted for the auth request

And when the authentication is automated via interception (subscribed to the auth request with the interception):

• network.beforeRequestSent for the original
• network.authRequired for the original
• network.continueWithAuth for the original (sent by the automation client, dialog is not shown)
• network.responseStarted for the original
• network.responseComplete for the original

I will need to also check the case when the event is subscribed to but the interception is off.

[jgraham]

I was wondering about this in the context of redirects as well

For redirects this is intentional; the idea is that request id refers to the entire redirect chain and we keep a redirect count to distinguish specific individual requests.

Since CORS preflight creates a totally new request object I think it will look like a different, unrelated request, which is kind of the opposite problem to this one. The problem with HTTP Auth is that in fetch we reuse the same request object for both the initial request and the request with credentials.

[annevk]

Hmm so when you're talking about "request objects" it seems like you're talking about the request concept in Fetch, which is mostly just a specification construct. And whether we create a new one or reuse one is mostly an artifact of what seemed convenient and not necessarily the best API. (Now perhaps it is the best API, but wanted to make sure you realize that.)

[juliandescottes]

Right we've been relying on the fetch request concept to decide whether or not we should create new requests / request ids. If this concept is not really something stable we can use as an API, then we either need to make it clear in fetch or to use something else?

So far it has worked pretty well, but as we see here we have scenarios where some requests will not exactly follow the standard network event lifecycle: beforeRequestSend -> responseStarted -> authRequired (optional) -> responseCompleted or fetchError

That being said we have not really decided if this should really be identical for all network events or if there could be exceptions.

From a BiDi user perspective, it feels that dealing with several network events with the same name for the same request id would be complicated. If we don't want to use another id, maybe we should do the same as for redirects and introduce an authenticationAttempt counter?

[annevk]

I think I would prefer you all to figure out when you want new request IDs independently from the request concept. Once we land the request IDs in Fetch we'll obviously keep them stable from then on out.

If request IDs survive redirects, I think it would make sense for them to survive CORS preflight and HTTP authentication as well. Those are all "additional requests" somewhat internal to the networking layer. Having said that, I'm not familiar with all the use cases so perhaps there are good reasons to deviate here and there.