Connection Allowlist in Early Hints Responses

[xiaochen-z]

The explainer does not cover connection allowlist's behavior in 103 Early Hints responses. My recommendation is to ignore connection allowlist in Early Hints response headers.

• During the Early Hints phase, the trusted server initiates pre-* requests; we can safely allow them.
• Enforce the connection allowlist upon the final response. Page content can make network requests, introducing exfiltration risks.

Context:

1. The standard permits multiple, inconsistent Early Hints responses.
2. Chromium implementation ignores the second and subsequent Early Hints responses.
3. The standard mandates that Early Hints response evaluation must not affect final response processing.

Enforcing connection allowlist in Early Hints introduces complexity regarding inconsistency between the Early Hints allowlist and the final response allowlist. A similar issue regarding CSP and Early Hints (see httpwg/http-extensions#687 (comment)) concluded that we should "take CSP into account for each 103 response individually".

[shivanigithub]

• During the Early Hints phase, the trusted server initiates pre-* requests; we can safely allow them.

To clarify, any pre-* requests from the content of the document will still be restricted using connection allowlists header, just not the ones that are present in the 103 response headers.
Makes sense and will wait for @mikewest's thoughts as well.