User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:55.0) Gecko/20100101 Firefox/55.0 Build ID: 20170824053622 Steps to reproduce: I develop a site that uses the Strict-Transport-Security header. Actual results: It works as it should in our testing and production environments, but on my local development machine, it spams the developer tools console with several copies of this message: Strict-Transport-Security: The connection to the site is untrustworthy, so the specified header was ignored. I guess there is one copy for each sub-resource the page loads. I know Strict-Transport-Security does not work on localhost when using a self-signed certificate, but this constant reminder of this fact makes it very hard to spot real errors and warnings in the console among the tens to hundreds of useless Strict-Transport-Security error messages. Expected results: This error message should not be shown when connecting to a locally hosted page with a self-signed certificate. Or at least it should only be shown once instead of multiple times. Google Chrome does not show this error message in its console for the same site. As a workaround, I could add code to not send the header when I build my web application for local development, but I prefer to avoid adding things to my web app that is different between development and production, because it makes testing much harder.
Christoph, I'd like to discuss what our options are here to make this error less noisy in the console. I also wonder why Chrome isn't showing a message at all in this case - it would help if we had a test page showing various STS configurations and errors. I couldn't find one with a quick search but maybe you know of one. The two suggestions in Comment 0 are either: 1. This error message should not be shown when connecting to a locally hosted page with a self-signed certificate. 2. Only show the error once instead of multiple times (presumably one per sub resource) Do either of these sound good, or do you have other ideas?
(In reply to Brian Grinstead [:bgrins] from comment #1) > Christoph, I'd like to discuss what our options are here to make this error > less noisy in the console. I think David might be the better person to assist with that.
Both options sound like improvements, although for option 1, note that there are other warnings that may be displayed that would still be relevant to a developer (e.g. warnings about not being able to parse the header, etc.)