To csharrison@: Yes, all main frame navigation redirects to an HTTP URL would be upgraded to HTTPS.
On fallback, Chrome adds the hostname of the original HTTP URL to an allowlist and will skip upgrading requests to that hostname in the future (this is currently remembered for a period of 7 days). Chrome also has an enterprise policy allowlist to exempt hostnames from being upgraded, and we are adding an "escape hatch" to skip upgrading if the user explicitly types in a URL starting with "http://"; in the Omnibox. Upgrades would continue to apply to each non-allowlisted HTTP hop in a navigation until either (1) a redirect loop is detected, (2) a network error occurs, or (3) our "fast fail" timeout triggers (Chrome currently uses a 3s timer to prevent navigations from hanging and then fails the navigation, which triggers our fallback logic). On Thu, May 25, 2023 at 8:31 AM Charles Harrison <csharri...@chromium.org> wrote: > I didn't quite understand from the explainer, but is the intention that > HTTP redirects will always be upgraded *unless* it results in a redirect > loop? Are there other cases where redirects will not be upgraded. > > On Thu, May 25, 2023 at 9:49 AM Rik Cabanier <caban...@gmail.com> wrote: > >> >> >> On Wed, May 24, 2023 at 4:43 PM Chris Thompson <cth...@chromium.org> >> wrote: >> >>> We're planning to roll this out as a field trial, hopefully starting in >>> Chrome 115 at 1% Stable in order to keep an eye impact. We've been testing >>> our implementation in Chrome Canary/Dev/Beta channels for a while now to >>> help test the feature and polish our implementation, which largely builds >>> on Chrome's existing "HTTPS-First Mode" (which is enabled for users who >>> toggle the "Always use secure connections" opt-in in Chrome's settings). >>> >> >> Thanks! >> How are you going to measure the impact? Do you keep an eye on bad >> redirects, hangs, people complaining? >> Also, will you send out a followup when you go to 100% (or revert)? We'd >> like to turn this on in our chromium based browser as well. >> >> >>> We didn't think that this was a good fit for an Origin Trial as it isn't >>> really site (or user) exposed. >>> >>> On Wed, May 24, 2023 at 4:36 PM Rik Cabanier <caban...@gmail.com> wrote: >>> >>>> This is an awesome change that will make the web better! >>>> Did you run any experiments or origin trials to see how it works in the >>>> field? Are you planning on rolling it out slowly to see the impact? >>>> >>>> On Wed, May 24, 2023 at 4:13 PM Chris Thompson <cth...@chromium.org> >>>> wrote: >>>> >>>>> Contact emailscth...@chromium.org, dadr...@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/CALMy46TuPDmzpr8udxXEythTCMVDBVVuTKwQivGGxm5fhJ-Xfg%40mail.gmail.com >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALMy46TuPDmzpr8udxXEythTCMVDBVVuTKwQivGGxm5fhJ-Xfg%40mail.gmail.com?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/CAGN7qDAP_u0PRqva-_SPqeJcR8BLRV4EdpspROA7FAEvVKv-fA%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGN7qDAP_u0PRqva-_SPqeJcR8BLRV4EdpspROA7FAEvVKv-fA%40mail.gmail.com?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/CALMy46RKRSq-XogCnvuESyoDPPUeqZRtWBwvxj%3D3WCQb_tLTQA%40mail.gmail.com.
