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