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/CALMy46S7P-3hmZAkXrFb_jPQ3eRGTcyVmWLBWZANHr40wnQ_tQ%40mail.gmail.com.
