CL that creates Mixed Content issues in DevTools (not yet landed): https://chromium-review.googlesource.com/c/chromium/src/+/2116228
Our current, non-default mixed-content audit (#3953; --preset mixed-content) works like this:
- Do two passes: first is the defaultPass. The second is a special pass where we intercept
http: requests and attempt to load https:. (This extra pass is why we haven't added this audit to the default config.) For all http: requests from the defaultPass, if there was a successful load of the https: resource in the special pass the request as is deemed "upgradeable". This means the developer can simply replace http: with https: for this request and it will work. In essence, we're just doing this extra pass so we can be more useful in the report. (ie "The request is on HTTP, BUTTT You can just change the URL and it'll work!" vs "the request is on http.. and no idea if that resource is already available at HTTPS.")
The Mixed Content issues created for DevTools is different. It creates an issue for all http: requests. This is similar to what is-on-https already does. Additional information included is how the request was handled by the browser (MixedContentResolutionStatus - blocked, warned, upgraded).
Proposal:
- Use phrase "Mixed Content"
is-on-https audit in description
- Stronger language in https://web.dev/is-on-https/ docs re: upcoming changes to Chrome blocking content (I think images is the only remaining incoming change? https://blog.chromium.org/2019/10/no-more-mixed-messages-about-https.html )
- Use the new issue event in the
is-on-https audit (fallback to current impl. if not supported - drop after a few major Chrome versions)
- New column for how the browser handled the request -
MixedContentResolutionStatus
The missing ingredient for parity with LH's non-default mixed-content is determining which blocked/warned requests could be simply switched to https:. LH does an extra pass for that (must actually attempt to load the secure request), but maybe this could be built-in to the Chrome backend? Would the increase in actionability be worth it? cc @sigurdschneider
Useful Examples:
CL that creates Mixed Content issues in DevTools (not yet landed): https://chromium-review.googlesource.com/c/chromium/src/+/2116228
Our current, non-default
mixed-contentaudit (#3953;--preset mixed-content) works like this:http:requests and attempt to loadhttps:. (This extra pass is why we haven't added this audit to the default config.) For allhttp:requests from the defaultPass, if there was a successful load of thehttps:resource in the special pass the request as is deemed "upgradeable". This means the developer can simply replacehttp:withhttps:for this request and it will work. In essence, we're just doing this extra pass so we can be more useful in the report. (ie "The request is on HTTP, BUTTT You can just change the URL and it'll work!" vs "the request is on http.. and no idea if that resource is already available at HTTPS.")The Mixed Content issues created for DevTools is different. It creates an issue for all
http:requests. This is similar to whatis-on-httpsalready does. Additional information included is how the request was handled by the browser (MixedContentResolutionStatus- blocked, warned, upgraded).Proposal:
is-on-httpsaudit in descriptionis-on-httpsaudit (fallback to current impl. if not supported - drop after a few major Chrome versions)MixedContentResolutionStatusThe missing ingredient for parity with LH's non-default
mixed-contentis determining which blocked/warned requests could be simply switched tohttps:. LH does an extra pass for that (must actually attempt to load the secure request), but maybe this could be built-in to the Chrome backend? Would the increase in actionability be worth it? cc @sigurdschneiderUseful Examples: