Re: [whatwg/fetch] Editorial: Use controller for navigation redirect (PR #1469)

I audited the state which is not reset. That is the fetch params:

- request: this is the thing we need to preserve, and that the existing spec does
- algorithms: preserving these will make things easier, in the event we ever fix HTML to use them properly
- task destination, cross-origin-isolated capability: we don't want to reset these
- controller: seems to work well. The timing info being carried over is probably a win.
- timing info: this seems like a win.
- preloaded response candidate: not applicable to navigations, will always be null.

I overall agree with the idea that, since we don't reset this state during non-"manual" redirects, this change is an improvement since it makes "manual" redirects more like non-"manual" ones.

I might tweak this PR to change "next redirect steps" to "next manual redirect steps", and "process the next redirect" to "process the next redirect manually" or even "process the next HTTP redirect manually".

@annevk, what do you think? Can we merge this, if I rebase it and maybe perform those renames?

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

Message ID: <whatwg/fetch/pull/1469/c1277084925@github.com>