Re: [whatwg/fetch] Script-created redirects responses have no location URL (#1146)

#883 seems an orthogonal encoding issue, though yeah redirects are quite a mess. Maybe I'll take a stab at fixing that so the test no longer needs to be speculative. I think it's just a matter of adding a sentence to define the conversion from byte sequence to string. The conversion is a little goofy, but that goofiness does seem necessary for web compatibility.

#633 is interesting. It sounds like it's saying the response's URL list is not set by the time location URL is computed? If so, that would complicate option (3). Although, is that still the case? Looks like a response's URL list is set here:
https://fetch.spec.whatwg.org/#ref-for-concept-response-url-list%E2%91%A0%E2%93%AA

That's called here, which happens before the location URL is computed. So I think that means #633 is no longer necessary?
https://fetch.spec.whatwg.org/#ref-for-concept-http-network-or-cache-fetch%E2%91%A0

Regarding your WPT PR, if I'm reading it right, it captures the place where Chrome/Firefox currently diverge from the spec. It doesn't seem to capture the script-constructed redirects question in this issue. I independently wrote a test myself as part of fixing this in Chrome. Mine avoids the `evilGlobalState` variable, reuses fetch-rewrite-worker.js, and also tests the CacheResponse round-trip. I'm thinking I'll just check those tests in with my fix.

The issue is I need to pick a behavior for script-constructed redirects for the fix. There are a few options above. I like (2) or (3), with I think a slight preference for (3), but I don't feel strongly between the two. What do you think?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/1146#issuecomment-768502629