Hi Harald, The browser will do language negotiation with resend the request (only happen once) with accept-language:en to get a result with English page.
Victor On Saturday, May 21, 2022 at 8:38:47 AM UTC-4 Harald Alvestrand wrote: > So if my config is (no, en), the site supports (fr, en), the first > response will be in French with a Vary:(fr, en) header? Will the browser > automatically detect that a better alternative is available and re-ask, > imposing an extra RTT, or will the result remain French? > > fre. 20. mai 2022, 19:11 skrev 'Victor Tan' via blink-dev < > blink-dev@chromium.org>: > >> NOTES: This intend won't implement Variants in the HTTP cache. It only >> focus on using Variants http header as a support-languages head which in >> the definition on section 2 >> <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-variants-06#section-2> >> . >> >> On Thursday, May 19, 2022 at 10:20:29 AM UTC-4 vict...@chromium.org >> wrote: >> >>> Contact emails >>> >>> vict...@chromium.org, abe...@chromium.org >>> >>> Explainer >>> >>> >>> https://github.com/Tanych/accept-language >>> Specification >>> >>> Variants header: >>> https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-variants-06 >>> >>> Summary >>> >>> Support the HTTP Variants header and implement the reduction of >>> information that could be used for fingerprinting in the Accept-Language >>> header, so that Chrome only sends the user’s most preferred language in the >>> Accept-Language header on the initial request. >>> Blink component >>> >>> Privacy>Fingerprinting >>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Privacy%3EFingerprinting> >>> >>> Motivation >>> >>> >>> The Accept-Language header is a source of passive fingerprinting >>> information about users, as it can contain a high degree of entropy, >>> particularly if the user has many accepted languages. >>> >>> Chrome (and other browsers) send a full list of the user's accepted >>> languages on every HTTP request via the Accept-Language header. While some >>> sites use this information for content negotiation, servers can also >>> passively capture this information without the user's awareness, to >>> fingerprint a user. >>> >>> We propose to only send a single language—one of the user’s preferred >>> languages determined by the language negotiation process—in the >>> Accept-Language request header by default. Here’s what that would look like >>> when a user tries to access https://example.com: >>> >>> Get / HTTP/1.1 >>> >>> Host: example.com >>> >>> Accept-Language: en >>> >>> HTTP/1.1 200 OK >>> >>> Content-Language: en >>> >>> Vary: Accept-Language >>> >>> Variants: Accept-Language=(en) >>> >>> As the response shows, in addition to the Content-Language in the >>> response header, sites will respond with a Variants >>> <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-variants-06> >>> header (support for which will be prototyped as part of this intent), the >>> value of which includes all the languages the site supports. Browsers can >>> use the Variants header to do language negotiation if sites offer a page in >>> a language that doesn’t match the user's preferred languages. Initial >>> public proposal >>> >>> >>> https://discourse.wicg.io/t/proposal-reduce-fingerprinting-in-the-accept-language-header/5835 >>> >>> >>> >>> TAG review >>> >>> To be filed. >>> >>> RisksInteroperability and Compatibility >>> >>> We are reducing the number of languages sent in the Accept-Language >>> header to protect user privacy. The main source of risk is that sites rely >>> on all or part of a user’s preferred languages instead of the most >>> preferred language. We feel it’s important to minimize the breakage of the >>> features depending on Accept-Language as much as possible, to maintain >>> stability of the web ecosystem. To mitigate the risk of this change, we >>> intend to gradually roll it out via Finch configuration and keep monitoring >>> health metrics and bug reports from the community. >>> >>> Gecko: No signals >>> >>> WebKit: No signals >>> >>> Web developers: See the explainer for details. >>> Debuggability >>> >>> No special DevTools support needed. >>> >>> Is this feature fully tested by web-platform-tests >>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >>> ? >>> >>> It will be. >>> >>> Flag name >>> >>> reduce-accept-language >>> >>> >>> Requires code in //chrome? >>> >>> False >>> >>> Tracking bug >>> >>> https://bugs.chromium.org/p/chromium/issues/detail?id=1306905 >>> >>> >>> *Launch bug* >>> https://bugs.chromium.org/p/chromium/issues/detail?id=1307484 >>> >>> *Link to entry on the Chrome Platform Status* >>> https://chromestatus.com/feature/5188040623390720 >>> <https://chromestatus.com/feature/5188040623390720#details> >>> >>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "blink-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to blink-dev+unsubscr...@chromium.org. >> To view this discussion on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/12b25cad-3902-4a09-bd9c-3c30a3b41ab6n%40chromium.org >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/12b25cad-3902-4a09-bd9c-3c30a3b41ab6n%40chromium.org?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/33e5ee4f-d074-474b-bcb9-6aa4630c8a00n%40chromium.org.
