Skip CORS header checks for preflights only sent for PNA

[johnathan79717]

To protect navigations to private network devices, we might also send preflights before the actual request. Currently, if the request's mode is 'navigate', the fetch algorithm only runs a scheme fetch. We will probably need to modify it so that it can send a preflight for navigations.

[johnathan79717]

While prototyping, I found that Chrome sends a long Accept header in navigation requests that exceeds the safe 128 character limit, resulting the requests failing CORS checks. Would it be reasonable to relax the restriction to, say 256?

[annevk]

It seems to me that the only determination for a non-CORS-PNA preflight request should be around the request's URL's host.

Why are you looking at the request's header list at all?

[johnathan79717]

I guess it's just that when we hooked the implementation onto Chrome's existing CORS implementation, it triggers the same header checks as other CORS preflight requests. I take it that specification-wise, the non-CORS-PNA preflight requests don't need to go through the same checks? In that case, I'll try to update our implementation and try to avoid the same checks on those non-CORS-PNA preflight requests.

[annevk]

I guess I don't really understand what reusing CORS directly would mean here. The threat model is completely different. In these navigation requests the headers are not attacker-controlled. And the only condition we use for sending a preflight or not is whether or not we target a different IP address space. To see if that new IP address space is okay with us contacting it. I don't see how headers would be an additional consideration.

[johnathan79717]

Updated the explainer in https://github.com/WICG/private-network-access/commit/190f5d71ee6d782a1821a03947ab679d90fddda5