Same situation here @Franky I'm working for a mobile payment service provider that offers mobile payment in multiple countries in Europe. Multiple mobile network operators in Europe like few ones in Poland currently only support end user identification via header enrichment!
The header enrichment is used for an automatic silent end user identification that allows service providers in subsequent flow (of course via https!) to: a) auto-login an already known end user in mobile web b) offer an end-user the possibility to purchase a good/service without need to enter mobile phone number of a user in mobile web (which would require a media break to validate the number via SMS). The enforced https upgrade has a huge negative impact on usability of such services for end-users in mobile web: Flow that worked automatically in the past gets now interrupted by a request for confirmation for an unsecure flow -> scares a lot of people as it looks very unprofessional. Hope you have a realizable idea to deal with this use case, to offer end users a good user experience again! (changing identify flow from HE to redirect loop ot mobile network operator is unfortunately not, as they have very limited ressources :( ) Franky Rios schrieb am Freitag, 27. Oktober 2023 um 23:47:08 UTC+2: > I have a website that needs to receive "Header Enrichment" over HTTP, > which reads the MSISDN when the user browses via their mobile data. > > Previously, the user accessed via HTTPS, and we would switch to HTTP to > perform the "Header Enrichment" reading and then switch back to HTTPS. > > With this update, I see that there is a Non-Authoritative-Reason: > HttpsUpgrades. It stops the HTTP request and switches it to HTTPS. This > prevents me from performing the "Header Enrichment" injection reading over > HTTP. > > What solution could you provide? Is there any way from my infrastructure > to block this Non-Authoritative-Reason: HttpsUpgrades, in other words, to > block Chrome from redirecting me to HTTPS? > > > > > > > El martes, 17 de octubre de 2023 a la(s) 01:50:31 UTC-5, Mike West > escribió: > >> Fantastic, thanks for the update. Hope it sticks! >> >> -mike >> >> On Mon, Oct 16, 2023 at 20:15 Chris Thompson <cth...@chromium.org> wrote: >> >>> We enabled HTTPS-Upgrades by default on trunk last week, and are >>> currently rolling out to 100% Stable. >>> >>> On Thu, Oct 5, 2023 at 10:42 AM Chris Thompson <cth...@chromium.org> >>> wrote: >>> >>>> This week we increased the rollout of HTTPS Upgrades up to 35% Stable. >>>> We are continuing to monitor issues and feedback. Given that we have not >>>> heard any unexpected feedback yet we are planning to proceed to 100% >>>> Stable >>>> next week. >>>> >>>> On Fri, Sep 1, 2023 at 10:42 AM Chris Thompson <cth...@chromium.org> >>>> wrote: >>>> >>>>> This is currently enabled at 20% Stable. We have not heard any >>>>> unexpected feedback yet, and are continuing to monitor for issues and >>>>> feedback. >>>>> >>>>> On Thu, Aug 24, 2023 at 9:51 AM Daniel Bratell <brat...@gmail.com> >>>>> wrote: >>>>> >>>>>> Same (LGTM). >>>>>> >>>>>> I assume you have also not had any unexpected feedback. The methods >>>>>> you added to force http seemed adequate but you never know when you >>>>>> encounter the wild wild web. >>>>>> >>>>>> /Daniel >>>>>> On 2023-08-23 18:45, Chris Harrelson wrote: >>>>>> >>>>>> Still LGTM from me too. >>>>>> >>>>>> On Wed, Aug 23, 2023 at 8:58 AM Yoav Weiss <yoav...@chromium.org> >>>>>> wrote: >>>>>> >>>>>>> Still LGTM >>>>>>> >>>>>>> On Wed, Aug 23, 2023 at 5:47 PM Chris Thompson <cth...@chromium.org> >>>>>>> wrote: >>>>>>> >>>>>>>> We have iterated on the Fetch spec PR >>>>>>>> <https://github.com/whatwg/fetch/pull/1655> and believe it is >>>>>>>> ready to land modulo some editorial tweaks. >>>>>>>> >>>>>>> >>>>>>> Please be sure to follow up on the PR once the reviewers get back to >>>>>>> it. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> From our 1% Stable experiment, we saw a substantial decrease in >>>>>>>> insecure plaintext HTTP navigation requests, and no regressions in >>>>>>>> Core Web >>>>>>>> Vitals metrics. >>>>>>>> >>>>>>>> We would like to proceed with this Intent-to-Ship, doing a gradual >>>>>>>> rollout to 100% in order to continue monitoring potential breakage. >>>>>>>> >>>>>>>> We did see a possible regression in renderer crash proportion, but >>>>>>>> we have not been able to identify a plausible cause or crash >>>>>>>> signature. Due >>>>>>>> to this possible stability risk we will be coordinating our gradual >>>>>>>> rollout >>>>>>>> with release owners. I can update this thread each time we increase >>>>>>>> our >>>>>>>> rollout percentage. >>>>>>>> >>>>>>>> - Chris >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Jul 19, 2023 at 9:01 PM Yoav Weiss <yoav...@chromium.org> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> LGTM3 with similar conditions. If the PR takes an unreasonable >>>>>>>>> amount of time to land, please let us know. >>>>>>>>> >>>>>>>>> On Wed, Jul 19, 2023 at 9:02 PM Chris Harrelson < >>>>>>>>> chri...@chromium.org> wrote: >>>>>>>>> >>>>>>>>>> LGTM2 with the same conditions as Daniel. Thanks also for >>>>>>>>>> following up with a summary before proceeding with rollout! >>>>>>>>>> >>>>>>>>>> On Wed, Jul 19, 2023 at 11:56 AM Chris Thompson < >>>>>>>>>> cth...@chromium.org> wrote: >>>>>>>>>> >>>>>>>>>>> Thanks Daniel. As a quick update, this was just enabled at 1% >>>>>>>>>>> Stable in M115 (released yesterday). We have not seen any blockers >>>>>>>>>>> come up >>>>>>>>>>> from Beta, but since issues may arise mainly in the long tail of >>>>>>>>>>> sites we >>>>>>>>>>> might not see anything until Stable anyway. We'll keep an eye on >>>>>>>>>>> our >>>>>>>>>>> experimental rollout and follow up here with a summary. >>>>>>>>>>> >>>>>>>>>>> On Wed, Jul 19, 2023 at 11:52 AM Daniel Bratell < >>>>>>>>>>> brat...@gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> I've been waiting a bit to see if the experiment would blow >>>>>>>>>>>> anything up, but if it doesn't, and continue to not do so, then >>>>>>>>>>>> >>>>>>>>>>>> LGTM1 as soon as the PR has landed. >>>>>>>>>>>> >>>>>>>>>>>> /Daniel >>>>>>>>>>>> On 2023-06-14 17:40, Yoav Weiss wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Thursday, June 8, 2023 at 5:53:49 PM UTC+2 Chris Thompson >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Jun 7, 2023 at 9:41 PM Yoav Weiss <yoav...@chromium.org> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Thanks for working on this! >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Jun 7, 2023 at 11:44 PM Chris Thompson < >>>>>>>>>>>> cth...@chromium.org> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Thanks all. Some updates: >>>>>>>>>>>> >>>>>>>>>>>> - We have filed a TAG review request >>>>>>>>>>>> <https://github.com/w3ctag/design-reviews/issues/853> >>>>>>>>>>>> - We are working on writing WPTs and we will update this >>>>>>>>>>>> thread when those are ready -- thanks for the added details >>>>>>>>>>>> about how those >>>>>>>>>>>> are run >>>>>>>>>>>> - We have added a `Non-Authoritative-Reason: HttpsUpgrades` >>>>>>>>>>>> header to the synthetic redirects (CL >>>>>>>>>>>> >>>>>>>>>>>> <https://chromium-review.googlesource.com/c/chromium/src/+/4584420>, >>>>>>>>>>>> >>>>>>>>>>>> which we are planning to merge back to M-115) >>>>>>>>>>>> - We are continuing to iterate on the spec PR >>>>>>>>>>>> >>>>>>>>>>>> For now we will continue to provide updates on this I2S -- >>>>>>>>>>>> closer to M115 going to Stable we may send an I2E to request the >>>>>>>>>>>> ability to >>>>>>>>>>>> proceed with a 1% Stable experiment if we have not yet been able >>>>>>>>>>>> to resolve >>>>>>>>>>>> everything here. >>>>>>>>>>>> >>>>>>>>>>>> @Harald Alvestrand : In general, this feature should work fine >>>>>>>>>>>> with captive portals. A captive portal that intercepts HTTPS >>>>>>>>>>>> connections >>>>>>>>>>>> will result in a certificate error, which will cause the upgrade >>>>>>>>>>>> to fail >>>>>>>>>>>> and automatically fall back to HTTP. Alternatively, the captive >>>>>>>>>>>> portal >>>>>>>>>>>> could reset the connection for HTTPS requests, which would >>>>>>>>>>>> accomplish the >>>>>>>>>>>> same. >>>>>>>>>>>> >>>>>>>>>>>> We have had one report of a middlebox that returned an HTTP 404 >>>>>>>>>>>> error over HTTPS instead of rejecting the connection, causing >>>>>>>>>>>> breakage (the >>>>>>>>>>>> upgraded HTTPS page would load but have useless content). We do >>>>>>>>>>>> not believe >>>>>>>>>>>> the browser should fallback on *application* level errors, as >>>>>>>>>>>> they do not provide a useful signal that the site does not support >>>>>>>>>>>> HTTPS -- >>>>>>>>>>>> in the vast majority of cases the same application error will >>>>>>>>>>>> occur over >>>>>>>>>>>> HTTP as well. (This specific case was an enterprise situation, >>>>>>>>>>>> with an >>>>>>>>>>>> enterprise installed root certificate making the middlebox's HTTPS >>>>>>>>>>>> work, >>>>>>>>>>>> and we have enterprise policies to allow organizations to disable >>>>>>>>>>>> upgrades >>>>>>>>>>>> for affected hosts.) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> What's our plan to tackle such issues? Do we have an enterprise >>>>>>>>>>>> policy in place? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> We have two enterprise policies for this feature: >>>>>>>>>>>> >>>>>>>>>>>> - HttpsUpgradesEnabled >>>>>>>>>>>> >>>>>>>>>>>> <https://chromeenterprise.google/policies/#HttpsUpgradesEnabled> >>>>>>>>>>>> can >>>>>>>>>>>> be used to disable this feature on managed clients (we have a >>>>>>>>>>>> similar >>>>>>>>>>>> policy >>>>>>>>>>>> <https://chromeenterprise.google/policies/#HttpsOnlyMode> >>>>>>>>>>>> for Chrome's HTTPS-First Mode, i.e. the opt-in "Always use >>>>>>>>>>>> secure >>>>>>>>>>>> connections" setting) >>>>>>>>>>>> - HttpAllowlist >>>>>>>>>>>> <https://chromeenterprise.google/policies/#HttpAllowlist> can >>>>>>>>>>>> be used to allowlist hostnames or hostname patterns -- these >>>>>>>>>>>> will then not >>>>>>>>>>>> be upgraded on managed clients (this also applies to >>>>>>>>>>>> HTTPS-First Mode) >>>>>>>>>>>> >>>>>>>>>>>> There are two "escape hatches" for users who encounter breakage >>>>>>>>>>>> and need to fall back to HTTP, although from prior measurement we >>>>>>>>>>>> expect >>>>>>>>>>>> this to be rare: >>>>>>>>>>>> >>>>>>>>>>>> - If the user explicitly types an "http://"; URL into the >>>>>>>>>>>> Omnibox (with the scheme), we skip upgrading that navigation >>>>>>>>>>>> and add the >>>>>>>>>>>> host to the allowlist. >>>>>>>>>>>> - If the user sets the "Insecure Content" content setting ( >>>>>>>>>>>> chrome://settings/content/insecureContent) to "Allowed" for >>>>>>>>>>>> the site, then we skip upgrading navigations. (This setting >>>>>>>>>>>> also disables mixed >>>>>>>>>>>> content autoupgrading >>>>>>>>>>>> >>>>>>>>>>>> <https://w3c.github.io/webappsec-mixed-content/level2.html#upgrade-algorithm> >>>>>>>>>>>> -- >>>>>>>>>>>> for HTTPS Upgrades and HTTPS-First Mode we rely on Mixed >>>>>>>>>>>> Content Level 2 to >>>>>>>>>>>> ensure no plaintext subresource requests are sent.) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> That makes sense! >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Jun 7, 2023 at 1:02 AM Harald Alvestrand < >>>>>>>>>>>> h...@google.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>> How will this affect login to captive portals (WiFi login), >>>>>>>>>>>> which frequently rely on rewriting HTTP requests? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Jun 6, 2023 at 12:00 AM 'Panos Astithas' via blink-dev < >>>>>>>>>>>> blin...@chromium.org> wrote: >>>>>>>>>>>> >>>>>>>>>>>> On Wed, May 31, 2023 at 7:31 AM Mike West <mk...@google.com> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -mike >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Wed, May 31, 2023 at 4:17 PM Rick Byers <rby...@chromium.org> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> As a long-time user of HTTPS-first mode, I'm excited to see >>>>>>>>>>>> this ship ASAP! >>>>>>>>>>>> >>>>>>>>>>>> On Wed, May 31, 2023, 5:29 a.m. 'Mike West' via blink-dev < >>>>>>>>>>>> blin...@chromium.org> wrote: >>>>>>>>>>>> >>>>>>>>>>>> On Fri, May 26, 2023 at 1:32 AM Chris Thompson < >>>>>>>>>>>> cth...@chromium.org> wrote: >>>>>>>>>>>> >>>>>>>>>>>> On Thu, May 25, 2023 at 3:36 AM Mike West <mk...@chromium.org> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> I am enthusiastic about this (and not just because it should >>>>>>>>>>>> allow us to deprecate/remove `Upgrade-Insecure-Requests`). A few >>>>>>>>>>>> comments >>>>>>>>>>>> inline: >>>>>>>>>>>> >>>>>>>>>>>> On Thu, May 25, 2023 at 1:13 AM Chris Thompson < >>>>>>>>>>>> cth...@chromium.org> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Contact emailscth...@chromium.org, dadr...@google.com >>>>>>>>>>>> >>>>>>>>>>>> Explainerhttps://github.com/dadrian/https-upgrade/blob/main/ >>>>>>>>>>>> explainer.md >>>>>>>>>>>> >>>>>>>>>>>> Specificationhttps://github.com/whatwg/fetch/pull/1655 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks for putting this together! I'll leave some comments on >>>>>>>>>>>> the PR. Given that we haven't gotten any feedback from Fetch >>>>>>>>>>>> editors, it >>>>>>>>>>>> might be prudent to let them take a pass before locking in our >>>>>>>>>>>> current >>>>>>>>>>>> behavior. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Yes, hopefully we can get some feedback, but I'm optimistic >>>>>>>>>>>> that we won't be locking in behavior if we ship this as it should >>>>>>>>>>>> hopefully >>>>>>>>>>>> be not site or user visible, so if we need to change the behavior >>>>>>>>>>>> to align >>>>>>>>>>>> cross-browser we can iterate. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I left a few comments last week. I think the PR needs some work >>>>>>>>>>>> before we can reasonably expect it to land in Fetch. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I agree (and left a few comments of my own). Would it be >>>>>>>>>>>> possible to make some progress on this? Once the comments are >>>>>>>>>>>> addressed and >>>>>>>>>>>> we feel good about the PR's state, could we use the Mozilla >>>>>>>>>>>> position as >>>>>>>>>>>> support and publish the PR for review? (It's currently marked as a >>>>>>>>>>>> draft, >>>>>>>>>>>> which may explain why it wasn't reviewed by Fetch editors) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Friendly ping on making progress on the PR! :) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Do we have tests in place for this behavior in Web Platform >>>>>>>>>>>> Tests? https://wpt.fyi/results/mixed-content/ >>>>>>>>>>>> tentative/autoupgrades?label=experimental&label=master&aligned >>>>>>>>>>>> holds some tests for subresources, but I didn't see any around >>>>>>>>>>>> navigation or fallback behavior (which seems like it might need >>>>>>>>>>>> some WPT >>>>>>>>>>>> infrastructure change to produce a domain that's only served over >>>>>>>>>>>> HTTP). >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> We do not have Web Platform Tests but we can look into adding >>>>>>>>>>>> them. Currently this is implemented in //chrome which I think >>>>>>>>>>>> might make >>>>>>>>>>>> this more difficult (my understanding is that the WPT suite is run >>>>>>>>>>>> against >>>>>>>>>>>> content_shell rather than chrome). We are currently relying on >>>>>>>>>>>> browser >>>>>>>>>>>> tests for our integration testing. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> WPT is a pretty important part of shipping features that affect >>>>>>>>>>>> the platform. It would be ideal if we could share these tests with >>>>>>>>>>>> our >>>>>>>>>>>> friends at other vendors (and update existing tests that might be >>>>>>>>>>>> expecting >>>>>>>>>>>> different behavior). Shifting the implementation to //content to >>>>>>>>>>>> make that >>>>>>>>>>>> possible would also have the advantage of helping other Chromium >>>>>>>>>>>> embedders >>>>>>>>>>>> ship this feature, which would be excellent for consistency in the >>>>>>>>>>>> project. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Note that the official WPT results on wpt.fyi are using full >>>>>>>>>>>> Chrome builds. IIRC there are other features that require Chrome. >>>>>>>>>>>> I >>>>>>>>>>>> personally only consider having WPTs passing on upstream infra to >>>>>>>>>>>> be >>>>>>>>>>>> blocking I2S. @Panos Astithas can say more authoritatively. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Indeed, upstream WPT results use full Chrome (and Firefox, >>>>>>>>>>>> Safari, etc.) through wptrunner. Soon, this will also be the case >>>>>>>>>>>> when >>>>>>>>>>>> running WPT in Chromium CI on Linux, once some blockers have been >>>>>>>>>>>> resolved. >>>>>>>>>>>> >>>>>>>>>>>> Panos >>>>>>>>>>>> >>>>>>>>>>>> +1 to the benefits of having this in content, but I personally >>>>>>>>>>>> think that's outside the scope of API owners so not something that >>>>>>>>>>>> should >>>>>>>>>>>> block an I2S. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I agree with this. I didn't mean to imply that //content >>>>>>>>>>>> implementation was necessary, but that _having_ web platform tests >>>>>>>>>>>> is >>>>>>>>>>>> important for interop. Browser tests are less useful in that >>>>>>>>>>>> regard. :) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Summary >>>>>>>>>>>> >>>>>>>>>>>> Automatically and optimistically upgrade all main-frame >>>>>>>>>>>> navigations to HTTPS, with fast fallback to HTTP. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Blink componentInternals>Network>SSL >>>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3ENetwork%3ESSL> >>>>>>>>>>>> >>>>>>>>>>>> TAG reviewFetch change process does not mention a TAG review, >>>>>>>>>>>> therefore this is N/A (https://github.com/whatwg/ >>>>>>>>>>>> fetch#pull-requests) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Blink's process does mention a TAG review. I think it would be >>>>>>>>>>>> a good idea to put this in front of them. I also think they will >>>>>>>>>>>> appreciate >>>>>>>>>>>> it, since it's directly in line with their previous guidance (e.g. >>>>>>>>>>>> https://www.w3.org/2001/tag/doc/web-https). >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Sure, we can file a TAG review. I'll update this thread once >>>>>>>>>>>> that's done. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> TAG review statusNot applicable >>>>>>>>>>>> >>>>>>>>>>>> Risks >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Interoperability and Compatibility >>>>>>>>>>>> >>>>>>>>>>>> *Gecko*: Positive (https://github.com/mozilla/ >>>>>>>>>>>> standards-positions/issues/800) Firefox is offering a similar >>>>>>>>>>>> feature already in their private browsing mode by default >>>>>>>>>>>> >>>>>>>>>>>> *WebKit*: No signal (https://github.com/WebKit/ >>>>>>>>>>>> standards-positions/issues/185) >>>>>>>>>>>> >>>>>>>>>>>> *Web developers*: No signals. This feature is not exposed >>>>>>>>>>>> directly to web developers or users. However, HTTPS adoption is >>>>>>>>>>>> now >>>>>>>>>>>> standard practice (>90% of page loads in Chrome use HTTPS), and >>>>>>>>>>>> automatically upgrading navigations to HTTPS would avoid >>>>>>>>>>>> unnecessary >>>>>>>>>>>> redirects from HTTP to HTTPS for site owners. The >>>>>>>>>>>> `upgrade-insecure-requests` header has some similar functionality, >>>>>>>>>>>> and >>>>>>>>>>>> according to HTTP-Archive is found on ~6% of all requests. >>>>>>>>>>>> >>>>>>>>>>>> *Other signals*: >>>>>>>>>>>> >>>>>>>>>>>> WebView application risks >>>>>>>>>>>> >>>>>>>>>>>> Does this intent deprecate or change behavior of existing APIs, >>>>>>>>>>>> such that it has potentially high risk for Android WebView-based >>>>>>>>>>>> applications? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Debuggability >>>>>>>>>>>> >>>>>>>>>>>> Chrome will upgrade these navigations to HTTPS using a 307 >>>>>>>>>>>> internal redirect, which will be visible in the Network panel of >>>>>>>>>>>> Developer >>>>>>>>>>>> Tools. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> For HSTS, we synthesize a `Non-Authoritative-Reason` header on >>>>>>>>>>>> the synthetic redirect that tells developers why the redirect >>>>>>>>>>>> happened. Is >>>>>>>>>>>> that a pattern y'all will follow here as well? If so, it's >>>>>>>>>>>> probably a good >>>>>>>>>>>> idea to document it somewhere; I don't think we've explained that >>>>>>>>>>>> header >>>>>>>>>>>> well. :) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Good idea. I'll get a CL up to add this to our implementation, >>>>>>>>>>>> and it seems reasonable to merge back to M115. We can include a >>>>>>>>>>>> mention of >>>>>>>>>>>> it in any public facing documentation we write about this. I'm >>>>>>>>>>>> also looking >>>>>>>>>>>> into whether we can add NetLog events for the upgrade and fallback >>>>>>>>>>>> steps >>>>>>>>>>>> which could help with triaging bug reports. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks! >>>>>>>>>>>> >>>>>>>>>>>> Will this feature be supported on all six Blink platforms >>>>>>>>>>>> (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? >>>>>>>>>>>> No >>>>>>>>>>>> >>>>>>>>>>>> Currently not available on Android WebView. We are implementing >>>>>>>>>>>> this first for Chrome and will consider bringing this to WebView >>>>>>>>>>>> (likely as >>>>>>>>>>>> an embedder opt-in) as follow up work. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Is this feature fully tested by web-platform-tests >>>>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>>>>>>>> ?No >>>>>>>>>>>> >>>>>>>>>>>> Flag namehttps-upgrades >>>>>>>>>>>> >>>>>>>>>>>> Requires code in //chrome?True >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Can you spell out what's required here? Just enterprise policy >>>>>>>>>>>> work, or are there other things embedders would need to implement >>>>>>>>>>>> to make >>>>>>>>>>>> this functionality work? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> This feature is currently implemented in //chrome with some >>>>>>>>>>>> support code in content/'s NavigationRequest. I think it would be >>>>>>>>>>>> feasible >>>>>>>>>>>> to migrate the core of this into content/ -- we use an >>>>>>>>>>>> URLRequestLoaderInterceptor and a NavigationThrottle to implement >>>>>>>>>>>> the >>>>>>>>>>>> upgrading and fallback logic. This is currently shared with >>>>>>>>>>>> Chrome's >>>>>>>>>>>> HTTPS-First Mode (controlled by Chrome's "Always use secure >>>>>>>>>>>> connections" >>>>>>>>>>>> setting). If we did migrate this logic to content/, embedders >>>>>>>>>>>> would need to >>>>>>>>>>>> >>>>>>>>>>>> -- 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/a7e9f109-e943-4e01-8f89-f2142f120bf5n%40chromium.org.
