search

WICG / client-hints-infrastructure

Specification for the Client Hints infrastructure - privacy preserving proactive content negotiation
https://wicg.github.io/client-hints-infrastructure
Other
61 stars 26 forks source link

Define Critical-CH Restart logic more rigorously. #154

Open arichiv opened 1 year ago

arichiv commented 1 year ago

We need a formal way to indicate the entire navigation needs to be restarted from the top of the redirect chain.

eportis-cloudinary commented 1 year ago

Should Critical-CH restarts be limited to idempotent requests (or even just GET)?

miketaylr commented 1 year ago

Should Critical-CH restarts be limited to idempotent requests (or even just GET)?

Per https://github.com/WICG/client-hints-infrastructure/blob/main/reliability.md#retry-limits, it should be limited to just GET. I'm not sure what the Chromium implementation does tho.

yoavweiss commented 1 year ago

Per https://github.com/WICG/client-hints-infrastructure/blob/main/reliability.md#retry-limits, it should be limited to just GET. I'm not sure what the Chromium implementation does tho.

I guess we should verify there are tests to that effect..

arichiv commented 1 year ago

Chrome is actually limiting retries to once per origin per request. So if you have a chain like a.com -> b.com -> c.com your maximum retry chain length can look like a.com -(retry)> a.com -> b.com -(retry)> a.com -> b.com -> c.com -(retry)> a.com -> b.com -> c.com.

hiroshige-g commented 3 months ago

Also the current spec checks the Critical-CH on the result of creating navigation params by fetching, which is after all redirects. So if we also want to restart the request in the middle of redirects (e.g. for a 302 redirect response with Critical-CH), perhaps we should check Critical-CH during the while loop for redirects in creating navigation params by fetching and restart the loop.