Hello! On Sun, Feb 25, 2024 at 08:18:56PM +0100, Matthias Saou wrote:
> Hi, > > On Sat, 24 Feb 2024 03:02:35 +0300 > Maxim Dounin <mdou...@mdounin.ru> wrote: > > > Any specific details about "dropping the User-Agent"? From > > https://developers.google.com/privacy-sandbox/protections/user-agent > > it looks like User-Agent is still here, provides basic information > > about client browser version and platform, and it is not going > > anywhere. > > I got it wrong. Looks like all browsers are going to be Netscape 6.1 > until the end of times! :-) Well, not really, but the only meaningful information included now is: - browser name and version (also in Sec-CH-UA); - mobile flag (also in Sec-CH-UA-Mobile); - platform name (also in Sec-CH-UA-Platform). This is a lot, and I tend to think this should be enough for most sites. Still, it is certainly not the all information the browser can provide. > My particular issue is actually with what is now sometimes missing from > the User-Agent by default, such as the device brand (Samsung, > Xiaomi...) or the OS version (Windows 10 or 11...). > > If you know you need this data, then having a mechanism to keep having > it included in the first http client response would make things a lot > easier. Yep, device brand and OS version are not available by default now. > > Note that the draft-davidben-http-client-hint-reliability draft > > referenced in the Chrome feature (and the user-agent page) expired > > in 2021, and the same applies to the vvv-tls-alps and > > draft-vvv-httpbis-alps drafts. This makes it highly unlikely to > > be ever supported by OpenSSL. > > > > OTOH, if draft-davidben-http-client-hint-reliability is supported, > > the Critical-CH header should make it trivial (though potentially > > suboptimal, compared to ALPS) to request any specific hints if > > they are actually needed. Without ALPS implemented, using the > > Critical-CH header might be a good alternative. > > Thanks for the pointer! I just read up on > https://datatracker.ietf.org/doc/html/draft-davidben-http-client-hint-reliability > and the Critical-CH header probably wouldn't be suitable for our use > case (since it will typically trigger a second client connection), but > the ACCEPT_CH frame definitely would, especially given all these recent > clients would be connecting over HTTP/2 or newer. But that draft seems > to also have expired in 2021, no? Yep, the particular Chrome feature is based on this draft, and it expired in 2021. The difference between the Critical-CH header and the ACCEPT_CH frame sent via ALPS is that ALPS information is sent to the browser before the first request, so the browser is able to provide requested headers in the first request. With the Critical-CH header, the browser instead sees the list of requested headers with the first response. But it's browser's responsibility to retry the request with appropriate headers provided, so there is no need to do anything on the server side. That is, the Critical-CH header implies additional HTTP request, while ACCEPT_CH sent via ALPS implies additional information sent during SSL handshake. ALPS-based negotiation might be more optimal, but it's certainly a layering violation, and hence somewhat questionable solution (I haven't followed IETF discussions about the drafts, but I guess that's the main concern here, and might be the reason why these drafts expired). 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. > 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). -- Maxim Dounin http://mdounin.ru/ -- nginx mailing list nginx@freenginx.org https://freenginx.org/mailman/listinfo/nginx
