1899604 - For authentication requests all authentication attempts share the same request id as the original request

Status: NEW

(Remote Protocol :: WebDriver BiDi, defect, P1)

Description

[Julian Descottes [:jdescottes]]

STRs:

• subscribe to network events
• perform a request to a URL using http auth
• provide credentials (correct or wrong)

ER: Each request should have a unique request id (or should increase the redirectCount?)
AR: The original request and each authentication attempt have the same request id and redirectCount: 0

Comment 1

[Julian Descottes [:jdescottes]]

Hi James, I'm actually not 100% sure what is expected for authentication attempts. The request id is defined as

Each network request has an associated request id, which is a string uniquely identifying that request. The identifier for a request resulting from a redirect matches that of the request that initiated it.

For Firefox, we happen to use redirects in order to handle authentication attempts (although the redirectCount seems to remain 0, need to investigate this), but it's not clear from the fetch spec that the authentication attempts are actually redirects.

Do we know how authentication attempts should be identified? Different request id or same requst id + redirect count updated?

Comment 2

[Julian Descottes [:jdescottes]]

Not really related to the continueWithAuth command, let's block the event metas.

Comment 3

[James Graham [:jgraham]]

So looking at the spec it says:

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

fetchParams includes request as a field, so I think fetch is doing exactly the same as the implementation here and reusing the same request object. We aren't going via HTTP redirect fetch, so nothing updates the request count. So presumably you get a second beforeRequestSent event that's indistinguishable from the first. I agree that doesn't seem ideal and doesn't match the WebDriver model since you can't distinguish the two requests. I also think you only get a single responseCompleted event (for the second request).

Maybe we need a spec issue to understand if this model where the request with credentials effectively supersedes the original request is actually what we want.

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+1]]

We don't have P3's in a milestone. So I assume you meant to select P2 instead.

Comment 5

[Julian Descottes [:jdescottes]]

This actually blocks the test "network Page.authenticate should allow disable authentication" because we emit first a 401 responseCompleted and then a 200 responseCompleted witht he same request id and Puppeteer will mix the two because of that.

If we start generating unique ids for this special case the test starts passing. But it's not clear yet if this is what we should do spec wise (cf the comment from James above + https://github.com/w3c/webdriver-bidi/issues/722)