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
Fri Feb 23 17:09:02 UTC 2024
Hi,
With Chrome dropping the User-Agent in favor of Client Hints, I think
this problem is becoming more and more common: Keep identifying client
details and features on the first connection.
I won't go into details about Client Hints, but just mention that for
some weird (for me) reason, it was decided that the first connection
would always only provide limited client information, and it was up to
the web server to ask for more to be provided in the following
connections to the same hostname.
Apart from wasting connections and round trips by redirecting the
client to (almost) the same URL after having requested the additional
information, there exists a more efficient workaround, which is to
request the additional client information during the TLS handshake, so
that it can actually be provided during the first http request:
https://chromestatus.com/feature/5555544540577792
This doesn't seem to be currently supported in nginx, even when the
underlying TLS library does support ALPS extensions. There was one
attempt made at it two years ago, which can be seen in this commit
titled "Rough sketch of ACCEPT_CH HTTP/2 support through ALPS":
https://github.com/amtunlimited/nginx/commit/e810900a3e4844a9476cad1a9564e0ea7acc4455
I think this something that would make sense to try and include
directly into nginx now that Client Hints are being forced on everyone
by Chrome and Edge. Are there any newer known efforts to support it?
Cheers,
Matthias
More information about the nginx
mailing list