browser retries from the beginning of the multiple redirection with critical-ch

[jen6]

Hi, I'm working for an ad tech company. As part of the User Agent Reduction initiative (in Chrome), we (AB180 ad-tech company) are trying to implement browser hints with accept-ch and critical-ch. As I tested with critical-ch it retries the beginning of the redirection in each state. As #33 mentioned, "(1) Restart the request you're currently on, just with the new hints" is correct. But it acts like "(2) Restart from the beginning of the chain with the new hints". Is it just chrome's bug or updated spec?

I also made chrome bug issue.

Steps to reproduce the problem:

• How to reproduce
  1. Open Incognito window
  2. Open developer tools, Change to mobile mode and Dimensions to "Responsive" with 922x857 resolution.
  3. Go to https://abit.ly/kzjhsx
  4. Redirected to dev.ablog.airbridge.io

Problem Description:

• If the browser does not support client hint expected behavior is like below

  • abit.ly/kzjhsx -> dev.abr.ge/cctk0 -> dev.ablog.airbridge.io/~

• If the browser supports client hints

  • expected abit.ly/kzjhsx -(302 redirection)-> dev.abr.ge/cctk0 (204 response) -(browser retry)-> dev.abr.ge/cctk0 -(302 redirection)-> dev.ablog.airbrdge.io

  • but got abit.ly/kzjhsx -(302 redirection)-> dev.abr.ge/cctk0 (204 response) -(browser retry)-> abit.ly/kzjhsx -(302 redirection)-> dev.abr.ge/cctk0 -(302 redirection)-> ablog.dev.airbridge.io -(307 redirection browser retry)-> abit.ly/kzjhsx -(302 redirection)-> dev.abr.ge/cctk0 -(302 redirection)-> ablog.dev.airbridge.io

• additional information

  • abit.ly : no critical-ch related actions

  • dev.abr.ge

    • default headers
      • accept-ch: "Sec-CH-UA-Model, Sec-CH-UA-Platform-Version, Sec-CH-UA-Arch, Sec-CH-UA, Sec-CH-UA-Full-Version-List, Sec-CH-UA-WoW64"
      • permissions-policy: 'ch-ua-model=(self "https://ablog.dev.airbridge.io/"), ch-ua-platform-version=(self "https://ablog.dev.airbridge.io")'
    • behavior
      • if needed critical-ch browser retry return 204 response
        • with additional header 'critical-ch: "Sec-CH-UA-Model, Sec-CH-UA-Platform-Version"'
      • if critical-ch browser retry is not needed return 302 redirections to dev.ablog.airbridge.io

  • dev.ablog.airbridge.io

    • headers
      • accept-ch: "Sec-CH-UA-Model, Sec-CH-UA-Platform-Version, Sec-CH-UA-Arch, Sec-CH-UA, Sec-CH-UA-Full-Version-List, Sec-CH-UA-WoW64"
      • permissions-policy: 'ch-ua-model=(self "https://ablog.dev.airbridge.io/"), ch-ua-platform-version=(self "https://ablog.dev.airbridge.io")'
    • behavior
      • if needed critical-ch browser retry return 204 response
        • with additional header
          • critical-ch: "Sec-CH-UA-Model, Sec-CH-UA-Platform-Version"
      • if critical-ch browser retry is not needed return 200 response

[arichiv]

Interesting, I would have expected the chain:

abit.ly/kzjhsx -(302 redirection)-> dev.abr.ge/cctk0 (204 response) -(browser retry)-> dev.abr.ge/cctk0 -(302 redirection)-> dev.ablog.airbrdge.io (204 response) -(browser retry)-> dev.ablog.airbrdge.io

I'm not sure what's going on here, but I wonder if it's something to do with wanting to preserve the referrer and/or preventing one-time-use token breakage due to an unexpected retry in the middle of a chain. @yoavweiss and @miketaylr for other takes

[jen6]

@arichiv Can you explain why you expected one more retry in dev.ablog.airbridge.io? I added permissions-policy in dev.abr.ge to prevent retry in dev.ablog.airbridge.io.

Also, If I test without abit.ly (means starts from dev.abr.ge/cctk0) there is no retry in dev.ablog.airbridge.io.

[arichiv]

Client hints are cached per-origin, and permissions policies are uncached. If any origin returns a Critical-CH header because client hints were missing, the load must restart in order to return the (now cached) client hints requested. Permissions policies cannot delegate hints across redirects, just to subresources/frames on the same page.

If the request for client hints has already been cached, then no retry will occur as the critical-ch can be omitted/ignored since required hints were already sent.

[arichiv]

More details are in https://bugs.chromium.org/p/chromium/issues/detail?id=1346230, the TL;DR is:

I think the current behavior is unfortunately correct, and that any Critical-CH restarts in the redirection chain really do need to restart from the top rather than acting as though they started in the middle of it otherwise the behavior isn't actually identical.