Nginx support for TLS ALPS extension for ACCEPT_CH?

Matthias Saou thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net
Tue Feb 27 22:53:30 UTC 2024


Hi,

On Tue, 27 Feb 2024 22:44:34 +0300
Maxim Dounin <mdounin at mdounin.ru> wrote:

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

Unfortunately, if there's some related js included with all this, it's
100% static and best served from a CDN. The "dynamic" request goes to a
different hostname, to avoid being proxied for little gain through the
CDN. But returning the Accept-CH from the CDN alongside that js would
make a stronger case for considering doing that proxying. Thanks for
the suggestion!

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

Thanks for confirming! This will surely be the workaround that will be
tried first.

Matthias


More information about the nginx mailing list