Nginx support for TLS ALPS extension for ACCEPT_CH?

[Matthias Saou]

Hi,

On Mon, 26 Feb 2024 01:34:31 +0300
Maxim Dounin <mdounin at 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.

Delivering such a targeted ad currently requires only one http request.
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.

> > 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.

Cheers,
Matthias