-
Notifications
You must be signed in to change notification settings - Fork 9.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
new_audit: bring back redirects-http with passive https check #13548
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for late approval.
@@ -23,9 +23,14 @@ const config = { | |||
*/ | |||
const expectations = { | |||
lhr: { | |||
requestedUrl: 'https://jakearchibald.github.io/svgomg/', | |||
// Intentionally start out on http to test the redirect. | |||
requestedUrl: 'http://jakearchibald.github.io/svgomg/', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have a few redirects
smoke tests, should it go there instead?
Otherwise, please add an exclusion to these expectations so we can still run these smokes in devtools runner.
d157320
to
0efec59
Compare
@brendankenny branch updated |
0efec59
to
a598869
Compare
a598869
to
7759b98
Compare
Object.assign(/IndexedDB/, {_runner: 'devtools'}), | ||
// DevTools can't simply test a redirect, because the browser will have already navigated before the Lighthouse panel can begin. | ||
Object.assign(/redirected/, {_excludeRunner: 'devtools'}), | ||
], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤯
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤯
7759b98
to
c848f22
Compare
Object.assign(/IndexedDB/, {_runner: 'devtools'}), | ||
// DevTools can't simply test a redirect, because the browser will have already navigated before the Lighthouse panel can begin. | ||
Object.assign(/redirected/, {_excludeRunner: 'devtools'}), | ||
], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤯
It's been two years but it seems like this would still be useful. |
Doesn't appear to be any downsides to this. I'll update for 12.0. |
Aaaaactually I'm pretty sure So maybe we just close this? |
Conceptually they're different checks. The context of this PR is that there is a difference, and it would be little effort (and none of the complexity that prompted deleting the audit in the first place would be required) to keep the audit, so why not keep it. On the other hand, yes, a lot of overlap, and the path to being able to pass both if you start a LH run on an insecure URL is very narrow (just preloaded/cached HSTS these days? Any other approah?). In #3417 there was a proposal to relax My quick opinion two years later: I think it's still good to warn users when they're not using HTTPS or not upgrading, both of which #15907 communicates (albeit less clearly without a dedicated description). I wish we could do more with giving advice about the connection upgrade etc, but that's not the direction best practices is going, so it's fine. |
hot-take/needs-discussion PR: Bring back the
redirects-http
audit, but without the extra pass.requestedUrl
is onhttp
andfinalUrl
is onhttps
, passfinalUrl
isn't onhttps
, failrequestedUrl
is on any other scheme, notApplicableredirects-http
was removed in #12643 due to a history of debugger protocol issues, the massive slowness of an extra pass, and the fact that Chrome switched to https by default if a user doesn't supply a scheme.However there are still sites out there that should be redirecting to https and Lighthouse should continue to nudge the remaining 10-20% of sites people spend time on to do so if it's feasible.
We already have this audit in git history ready to go with just a few changes, and switching to only alerting when someone is purposefully testing their http site should take user complaints down to zero (for instance, the old check required the http version of a site to respond, if only to redirect), which also allows making the audit essentially zero-overhead by passively observing what the
URL
artifact is collecting anyways.Thoughts? :)