Re: [whatwg/fetch] Allow HTTP scheme fetches to make CORS preflight for navigations (PR #1785)

Thanks very much @annevk for the excellent review.

> I think these need to be separate steps as this is confusing. (Though not in the way you had before. Initialize the boolean in one step, then make the HTTP fetch call.)

I agree and I'll make that change.

> Then, I wonder if we need to identify these preflights are for navigations in some respect to the server as they might well want to enforce different policies between subresources and navigations. Perhaps Sec-Fetch-Dest suffices for that. Ideally we find something here that is unified with Private/Local Network Access.

Strongly support this. I wonder if `Sec-Fetch-Mode` also helps here—since we're using the `navigation` [request mode](https://fetch.spec.whatwg.org/#concept-request-mode), I think it follows that `Sec-Fetch-Mode`would unambiguously be set to `navigation`, even for the preflight. If PLNA didn't create a new mode, it would presumably also use this (if the request did originate from a link or form). 

> I would also like to research why we identify whether a request needs a preflight in two separate locations currently. I can't remember and having now read it a few times I don't understand. Any chance you want to dig into blame? If not I'll get to it in due course.

Happy to take a crack at it as well.

> The name *makeCORSPreflight* also seems rather confusing as it doesn't actually mean a CORS preflight will be made.

I defaulted to making as few changes as possible, although I completely agree (and that name certainly contributed to a couple extra hours of work trying to parse the spec). With your invitation I am happy to rename it—how do you feel about *allowCORSPreflight*?

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

Message ID: <whatwg/fetch/pull/1785/c2524387074@github.com>