Following links to some HTTPS sites is not standards-compliant |
|||||
Issue descriptionChrome Version : 57.0.2984.0 URLs (if applicable) : http://output.jsbin.com/bafifa Other browsers tested: Safari: OK Firefox: OK Edge: OK What steps will reproduce the problem? 1. Open http://output.jsbin.com/bafifa 2. Click on the link What is the expected result? Expect to get an SSL error about the certificate on https://www.kubernetes.io being bad (has a common name of just "kubernetes.io"). What happens instead of that? Magically navigates to "https://kubernetes.io/" Please provide any additional information below. Attach a screenshot if possible. The issue with kubernetes.io is here: https://github.com/kubernetes/kubernetes.github.io/issues/2371 But the interop concern here is that people like this don't realize their site is misconfigured (even if we generate a console warning), and then their site doesn't work in other browsers. So to do the right thing for the ecosystem we should either: 1) relax this handy feature to be strictly a UI feature that's not web-exposed (eg. when URLs are entered into omnibox, or as alternate UI on the SSL error page), OR 2) propose a specification change (eg. to the Fetch spec) and follow the blink launch process for changing web-exposed behavior: https://www.chromium.org/blink#TOC-Web-Platform-Changes:-Process meacer@ can you please add a link to the bug / commit that introduced this behavior? Thanks!
,
Mar 1 2017
Sure. This feature was implemented in bug 507454 and launched in M46. > 1) relax this handy feature to be strictly a UI feature that's not web-exposed (eg. when URLs are entered into omnibox, or as alternate UI on the SSL error page), OR If we end up with this route, I'd first like to fix bug 521832 (Record whether an SSL interstitial was initiated by the user or a page).
,
Mar 1 2017
Patrick Kettner from Microsoft Edge here This came to my attention during a discussion around letsencrypt. As it becomes simpler and easier for devs to add SSL, it seems less time is being spent on checking that it works cross browser. Folks are creating the cert for one version of the domain (whichever they type themselves, probably), loading in chrome to see if it works, then going along. I am still tracking down numbers to see what is a more common path for end user viewed cert errors internally (either via link or typed), but my gut is saying typed will probably win out. FWIW, I actually love this feature. I think it is a net-win for the web, just want all other browsers to get on board via some kind of standards track.
,
Mar 3 2017
,
Mar 6 2018
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Mar 7 2018
,
Aug 3
This bug has an owner, thus, it's been triaged. Changing status to "assigned". |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by rbyers@chromium.org
, Mar 1 2017