Oh, I see that "bloomberg.com" was added to "net/http/transport_security_state_static.json" in m116... that probably explains it. I can try remove it from the local build. Thanks so much for your help!
On Mon, Jul 10, 2023 at 8:24 PM Shezan Baig <shezbaig...@gmail.com> wrote: > Ahh, I see. Do you know if there is a switch to disable HSTS? (seems to > be a new behavior in m116) > Thanks, > -shez- > > > On Mon, Jul 10, 2023 at 8:22 PM Chris Thompson <cth...@chromium.org> > wrote: > >> This indicates that the upgrades are due to HSTS, so this is unrelated to >> HTTPS-Upgrades (this new feature). bloomberg.com is currently on the >> HSTS preload list, which also applies to subdomains. >> >> On Mon, Jul 10, 2023 at 5:18 PM Shezan Baig <shezbaig...@gmail.com> >> wrote: >> >>> I see the following in the netlog: >>> >>> t= 97 [st= 0] TRANSPORT_SECURITY_STATE_SHOULD_UPGRADE_TO_SSL >>> >>> * --> get_sts_state_result = true <--- this is false >>> in the m115 build* --> host = " >>> dsbeta.prod.bloomberg.com" >>> --> host_found_in_hsts_bypass_list = false >>> --> should_upgrade_to_ssl = true >>> t= 97 [st= 0] +URL_REQUEST_START_JOB [dt=25] >>> --> initiator = "not an origin" >>> --> load_flags = 65792 (CAN_USE_RESTRICTED_PREFETCH | >>> MAIN_FRAME_DEPRECATED) >>> --> method = "GET" >>> --> network_isolation_key = "http://bloomberg.com >>> http://bloomberg.com"; >>> --> request_type = "main frame" >>> --> site_for_cookies = "SiteForCookies: {site= >>> http://bloomberg.com; schemefully_same=true}" >>> --> url = " >>> http://dsbeta.prod.bloomberg.com/vrs2021/viewer/index.html"; >>> t= 97 [st= 0] URL_REQUEST_REDIRECT_JOB >>> --> reason = "HSTS" >>> t= 97 [st= 0] URL_REQUEST_FAKE_RESPONSE_HEADERS_CREATED >>> --> HTTP/1.1 307 Internal Redirect >>> Location: >>> https://dsbeta.prod.bloomberg.com/vrs2021/viewer/index.html >>> Cross-Origin-Resource-Policy: Cross-Origin >>> Non-Authoritative-Reason: HSTS >>> >>> >>> >>> On Mon, Jul 10, 2023 at 8:12 PM Shezan Baig <shezbaig...@gmail.com> >>> wrote: >>> >>>> I am using a locally built chrome.exe (so not one of the >>>> Canary/Dev/Beta channels), and doing the following: >>>> >>>> 116.0.5845.14/chrome.exe --proxy-server=<internal-proxy> http:// >>>> <internal-url> >>>> >>>> This causes the <internal-proxy> to get a "CONNECT <internal-url>:443", >>>> which unfortunately the proxy is not currently configured to handle >>>> properly (it blocks and times out after a minute). I can fix the >>>> <internal-proxy> to handle it correctly, but rolling out that change may >>>> take a while. >>>> >>>> In the meantime, I'm trying to workaround the issue by doing: >>>> >>>> 116.0.5845.14/chrome.exe --disable-features=HttpsUpgrades >>>> --proxy-server=<internal-proxy> http://<internal-url> >>>> >>>> However, that doesn't seem to make any difference (proxy is still >>>> getting a "CONNECT <internal-url>:443"). >>>> >>>> Note that our previous build (115.0.5790.32) does not do these >>>> upgrades, so I don't need any disable-feature switch for the m115 build. >>>> However, the m116 build does these upgrades with or without the >>>> disable-feature switch. >>>> >>>> Also note that these are locally built chromium binaries (not "Google >>>> Chrome"), so it will not participate in the 50% experiments. >>>> >>>> Thanks for your quick response! >>>> -shez- >>>> >>>> >>>> >>>> >>>> On Mon, Jul 10, 2023 at 7:47 PM Chris Thompson <cth...@chromium.org> >>>> wrote: >>>> >>>>> Could you provide more information on what is occurring (or maybe >>>>> better: file a bug at crbug.com/new with details and link it here)? >>>>> That's the correct flag to force-disable the feature (you can also disable >>>>> it during the experimental period in chrome://flags/#https-upgrades). >>>>> >>>>> Note that Chrome has other existing features which upgrade certain >>>>> navigations to HTTPS (such as schemeless URLs entered into the Omnibox), >>>>> so >>>>> you may be seeing those instead. HTTPS-Upgrades is currently only enabled >>>>> at 50% in Chrome Canary/Dev/Beta. >>>>> >>>>> On Mon, Jul 10, 2023 at 4:43 PM Shezan Baig <shezbaig...@gmail.com> >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> Is there a way to disable this feature? I tried running the browser >>>>>> with " --disable-features=HttpsUpgrades", but it still seems to be >>>>>> performing these upgrades. >>>>>> Thanks, >>>>>> -shez- >>>>>> >>>>>> >>>>>> On Wednesday, May 24, 2023 at 7:13:38 PM UTC-4 cth...@chromium.org >>>>>> wrote: >>>>>> >>>>>>> Contact emailscth...@chromium.org, dad...@google.com >>>>>>> >>>>>>> Explainer >>>>>>> https://github.com/dadrian/https-upgrade/blob/main/explainer.md >>>>>>> >>>>>>> Specificationhttps://github.com/whatwg/fetch/pull/1655 >>>>>>> >>>>>>> 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 >>>>>>> ) >>>>>>> >>>>>>> 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. >>>>>>> >>>>>>> >>>>>>> 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 >>>>>>> >>>>>>> Tracking bug >>>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1394910 >>>>>>> >>>>>>> Launch bughttps://launch.corp.google.com/launch/4235192 >>>>>>> >>>>>>> Sample links >>>>>>> http://example.com will upgrade to https://example.com. >>>>>>> http://www.alwayshttp.com will upgrade to https://www.alwayshttp.com but >>>>>>> fall back to http://www.alwayshttp.com because the site doesn't >>>>>>> support HTTPS. >>>>>>> >>>>>>> Estimated milestones >>>>>>> Shipping on desktop 115 >>>>>>> Shipping on Android 115 >>>>>>> >>>>>>> We are planning to do a field trial to gradually roll out this >>>>>>> feature to Chrome clients in Chrome 115. >>>>>>> >>>>>>> Anticipated spec changes >>>>>>> >>>>>>> Open questions about a feature may be a source of future web compat >>>>>>> or interop issues. Please list open issues (e.g. links to known github >>>>>>> issues in the project for the feature specification) whose resolution >>>>>>> may >>>>>>> introduce web compat/interop risk (e.g., changing to naming or >>>>>>> structure of >>>>>>> the API in a non-backward-compatible way). >>>>>>> https://github.com/whatwg/fetch/pull/1655 >>>>>>> >>>>>>> Link to entry on the Chrome Platform Status >>>>>>> https://chromestatus.com/feature/6056181032812544 >>>>>>> >>>>>>> Links to previous Intent discussionsIntent to prototype: >>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/mgJqym5-Xek/m/0EAN6v7CCQAJ >>>>>>> >>>>>>> This intent message was generated by Chrome Platform Status >>>>>>> <https://chromestatus.com/>. >>>>>>> >>>>>> -- 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/CANMpiORmPZU7R1Q_ffyiOut%2BcbKH19Be5kDOqUjww9xGRLHDYg%40mail.gmail.com.
