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