Define Critical-CH Restart logic more rigorously.

[arichiv]

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

[eportis-cloudinary]

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

[miketaylr]

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]

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]

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]

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.