Clarify response's url list state when parsing a 3xx response's Location header value

[harrishancock]

I'm trying to figure out the algorithm Fetch specifies for following redirects, but keep stumbling over whether or not the 3xx response's Location header is parsed relative to a base url. The Fetch spec implies it is parsed with the response's url as its base:

Fetch section 4.3, step 5:

5. If actualResponse’s status is a redirect status, then run these substeps:
   1. [...]
   2. Let location be the result of extracting header list values given Location and actualResponse’s header list.
   3. If location is a value, then set location to the result of parsing location with actualResponse’s url.

where "actualResponse's url" means the last response url in the response's url list. However, at the point in the algorithm I'm describing, I don't see how the response's url list can be anything other than null, which seems to imply that we're supposed to parse the Location header as an absolute url. That seems to contradict RFC 7231's definition of the Location header value:

RFC7231, section 7.1.2:

The field value consists of a single URI-reference. When it has the
form of a relative reference ([RFC3986], Section 4.2), the final
value is computed by resolving it against the effective request URI
([RFC3986], Section 5).

The situation I'm considering involves fetches originating from a service worker script, requesting resources from the same origin as the service worker's registration. The Location header parsing described above happens in the HTTP fetch algorithm Fetch section 4.3 which is ultimately called from step 5 of the main fetch algorithm (Fetch section 4.1). However, the response's url list is only ever set in step 9 of the main fetch algorithm ("If internalResponse’s url list is empty, then set it to a copy of request’s url list."), long after the response's Location header is supposed to have been parsed. Fetch section 2.2.6 says about the url list, "Unless stated otherwise, it is the empty list."

Am I interpreting something incorrectly? Or perhaps there's another specification which covers when a response's url list is set? I'd appreciate any clarification. Thanks!

[annevk]

Thanks, you found a bug. 😊

If we used the request's current url instead I think we'd be okay, except when the service worker returns an "opaqueredirect", but in that case I think we should be returning early and skip the redirect processing as it has already happened.

So I think we need to make two changes:

1. Use request's current url as base URL for redirects.
2. Add step 3.2.5: 'If response's type is "opaqueredirect", then return response.'

Would you like to be acknowledged as Harris Hancock?

@wanderview @yutakahirano @jakearchibald could you please review the above?

[wanderview]

Does using the Request.url handle the multiple redirect case? I think perhaps a second redirect should be relative to the first redirect URL?

Maybe we should continue using the Response.url, but add a step where we set Response.url to the Request.url for the first redirect.

[annevk]

It does, request's current url is updated upon a redirect. See step 13 of https://fetch.spec.whatwg.org/#http-redirect-fetch.

[harrishancock]

Would you like to be acknowledged as Harris Hancock?

Hey, that'd be great! Thank you for investigating and confirming this, @annevk.

[wanderview]

It does, request's current url is updated upon a redirect.

r+

[annevk]

Posted a PR, review appreciated.

[annevk]

See #1146 for some updates to this issue. We are getting closer to being able to finally close this.