-
Notifications
You must be signed in to change notification settings - Fork 253
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
Don't upgrade insecure requests when the page is served over HTTP #348
Comments
So upgrade-insecure-requests "works" on requests that themselves are not secure? I wasn't aware of that but I'm happy that it isn't the other way around. If that is intended behavior per the spec, we should still apply the header to all requests but provide an |
I'm marking this as a bug, so a fix for this will get ported to 4.x and 3.x |
Yeah, it could be a Chromium (56.0) bug, or a weird spec, or there's an odd reason this should work like this. In any case, a workaround would be greatly appreciated, so thanks! |
I suspect this "more secure by default" behavior was intentional, as is the
attitude towards most w3c webappsec standards. We should definitely support
the opt out behavior either way.
…On Thu, Jul 27, 2017 at 19:02 Guilherme Prá Vieira ***@***.***> wrote:
Yeah, it could be a Chromium bug, or a weird spec, or there's an odd
reason this should work like this. In any case, a workaround would be
greatly appreciated, so thanks!
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#348 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAbYBF6Xdp1ytCFjJZnwORN7Vhi7IAP9ks5sSWtcgaJpZM4OmHu7>
.
|
I don't have access to test this atm but I'm pretty sure Chrome no longer upgrades requests on localhost. I also filed https://bugzilla.mozilla.org/show_bug.cgi?id=1535919 and they confirmed Firefox shouldn't upgrade on localhost. |
Safari 14.0 (15610.1.28.1.9, 15610) still does try to upgrade localhost requests, FWIW. 😕 |
I guess |
2024 Safari Version 16.6 just found out I also experience this issue. |
2024 safari 17.4.1 same issue |
I want to set
upgrade_insecure_requests
only if the page is requested over HTTPS, because I don't use HTTPS when developing on localhost (i.e. when developing, I browse http://localhost, not https://localhost).Right now if I set
upgrade_insecure_requests
, I can't develop locally since all internal resource requests are upgraded, and since my local server doesn't support HTTPS, they fail.I think this should be a fairly typical scenario. Would this be considered a bug, or is there a work-around for it?
Relevant software versions
Expected outcome
upgrade_insecure_requests
.upgrade_insecure_requests
header shouldn't be set, since it's pointless as the webpage itself is being insecurely served.Actual outcome
upgrade_insecure_requests
header is set and all internal resources are broken.Config
Generated headers
The text was updated successfully, but these errors were encountered: