CORS preflight requests and UA-CH

[ronancremin]

Is there a consensus around whether or not a CORS preflight request should constitute the first request for the purposes of UA-CH?

In other words, if in response to a preflight request a server responds with an Accept-CH requesting high-entropy hints, should the next request from the browser (the first meaningful request with a surfaced response) send high entropy hints?

[miketaylr]

I think @yoavweiss might have more background on preflights and client hints generally (as this wouldn't be a UA-CH specific concern).

I see some related discussion in igrigorik/http-client-hints#68 and httpwg/http-extensions#141 (and following some breadcrumbs) - but I haven't had time yet to digest them.

[miketaylr]

(I'm gonna move this to the Client Hints Infra repo, I think it makes more sense over there)

[yoavweiss]

I see some related discussion in igrigorik/http-client-hints#68 and httpwg/http-extensions#141 (and following some breadcrumbs) - but I haven't had time yet to digest them.

IIRC, those are around whether CH should trigger preflights, not about whether they should be respected on ones.

In other words, if in response to a preflight request a server responds with an Accept-CH requesting high-entropy hints, should the next request from the browser (the first meaningful request with a surfaced response) send high entropy hints?

The Accept-CH opt-in is defined on a navigation response. I could be wrong, but I don't believe requests to such responses can have preflights. Do you have any specific example in mind where this may be the case?

[ronancremin]

I'm thinking though cases where JavaScript code on a page makes a request to a different origin for whatever reason—could be analytics or something like that. This would normally trigger a preflight request to the origin in question.

The question really boils down to whether or not the server response to the preflight request is considered by a browser in deciding what hints to send on subsequent requests.

But it sounds like you're saying the Accept-CH response header is defined only for navigation events as opposed to resources linked from 3rd party origins or Fetch/XHR events, is that right?

[yoavweiss]

But it sounds like you're saying the Accept-CH response header is defined only for navigation events as opposed to resources linked from 3rd party origins or Fetch/XHR events, is that right?

Indeed. We have Permission-Policy for delegation of hints to cross-origin resources.

[ronancremin]

Thanks Yoav.

Do you know if the logic around navigation responses is described somewhere without having to go through the WHATWG doc? It's not clear to me what responses constitute navigation responses. For example, do responses for requests for a page's linked resources constitute a navigation response?

[yoavweiss]

Do you know if the logic around navigation responses is described somewhere without having to go through the WHATWG doc?

I'm not sure. That spec is the authoritative place where that logic resides.

do responses for requests for a page's linked resources constitute a navigation response?

At the risk of not being 100% accurate, I'd say that navigation responses are responses that would be committed to a new document (either the top-level document or an iframe one). They are typically HTML responses, but could be e.g. an image response, if one is navigated to directly. Does that help?

[ronancremin]

Thanks Yoav.

From https://fetch.spec.whatwg.org/#navigation-request:

A navigation request is a request whose destination is "document", "embed", "frame", "iframe", or "object".

It doesn't explicitly define a navigation response but presumably it is the response to a navigation request.

It's still not clear to me from this definition what requests for a page's resources would be classified as, however.