Hello! On Mon, Feb 26, 2024 at 06:13:42PM +0100, Matthias Saou wrote:
> On Mon, 26 Feb 2024 01:34:31 +0300 > Maxim Dounin <mdou...@mdounin.ru> wrote: > > > [...] > > As far as I understand, the Critical-CH header should be good > > enough for most use cases, except might be for statistical > > counters which often use just one HTTP request, and therefore > > another one will be a huge change. > > > > If you are able to share, it would be great if you'll provide more > > details about your use case. > > A very simple use case is basic contextual ads. Presenting a somewhat > targeted ad with no user information, no session cookie, nothing more > than what a single http request provides. This means using in real time > things like the referer header, the accepted languages and the > user-agent string. > > The Mobile and Platform UA-CH headers do still provide the most > critical information for this, so it's more about the corner cases: If > an Android app is only compatible with Android 10 and up, you don't > want to be advertising to users of Android 9 and below. Thanks for the use case description. > Delivering such a targeted ad currently requires only one http request. You mean - only one http request, assuming the javascript code to show ads is previously loaded from another domain? Note that loading the code from the same origin with appropriate Accept-CH header might be the way to go. > But with a reduced User-Agent and the Platform-Version CH header > missing, it's no longer possible. What can be tried is: > > * Replying with the Critical-CH header. The client might then re-request > an ad... or not, which will skew things quite a bit. > * Redirect the client in order to request the header. You expose > yourself to potential infinite redirection bugs and use more > resources because of the extra http request. Yep, Critical-CH is, basically, a simpler alternative to error-prone redirects with Accept-CH. It doesn't save a backend request though, in case the first response is not really used due to re-request with critical hints provided. Another alternative might be to use Accept-CH, and do not show versions-specific ads to clients without platform version provided. That is, such ads will be shown only to clients which did more than one request. Might be good enough for a corner case. > > > So it seems like as of right now, with recent Chrome & Edge clients, > > > there is no way to have nginx receive more than the 3 default client > > > hints during the first client http connection? > > > > Yes, there is no support now (except the patch you've mentioned). > > I *really* wanted to avoid having to dig that patch up and potentially > have to switch TLS library just to make this work! :-) > > I also wanted to avoid having to implement a redirection in nginx, but > I think I will have to also try something like this out in case it does > end up working reliably: > > * If our parameter indicating we already redirected is missing, > * And the UA-CH Mobile header is present, > * And the UA-CH Platform-Version header is absent, > * Then redirect to the same URL but appending our parameter indicating > we already redirected. > > This way it could potentially still achieve triggering a single request > to the backend nginx is using, that would include the Platform-Version > if the client agreed to provide it. Yep, looks correct and safe enough, in case the goal is to save backend requests. -- Maxim Dounin http://mdounin.ru/ -- nginx mailing list nginx@freenginx.org https://freenginx.org/mailman/listinfo/nginx
