Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upDon'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. |
I want to set
upgrade_insecure_requestsonly 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_requestsheader shouldn't be set, since it's pointless as the webpage itself is being insecurely served.Actual outcome
upgrade_insecure_requestsheader is set and all internal resources are broken.Config
Generated headers