title: Mixed-content warning from Chrome 87 when accessing HTTP image source from an HTTPS page
body: <p>We have an in-house (.Net) application that runs on our corporate desktops. It runs a small web server listening on for HTTP requests on a specific port on <code>localhost</code>. We have a separate HTTPS website that communicates with this application by setting the <code>ImageUrl</code> of a hidden image to the URL of the  - this invokes an HTTP request to <code>localhost</code>, which the application picks up on and actions. For example, the site will set the URL of the image to:</p>
  <pre><code>http://127.0.0.1:5000/?command=dostuff
  </code></pre>
  <p>This was to work around any kind of &quot;mixed content&quot; messages from the site, as images seemed to be exempt from mixed-content rules. A bit of a hack but it worked well.</p>
  <p>I'd seen that Chrome was making moves towards completely blocking mixed content on pages, and sure enough Chrome 87 (currently on the beta channel) now shows these warnings in the Console:</p>
  <blockquote>
  <p>Mixed Content: The page at 'https://oursite.company.com/' was loaded
  over HTTPS, but requested an insecure element
  'http://127.0.0.1:5000/?command=dostuff'. This request was
  automatically upgraded to HTTPS, For more information see
  <a href="https://blog.chromium.org/2019/10/no-more-mixed-messages-about-https.html" rel="nofollow noreferrer">https://blog.chromium.org/2019/10/no-more-mixed-messages-about-https.html</a></p>
  </blockquote>
  <p>However, despite the warning saying the request is being automatically upgraded, it hasn't been - the application still gets a plain HTTP request and continues to work normally.</p>
  <p>I can't find any clear guidance on whether this warning is a &quot;soft fail&quot;, and whether future versions of Chrome will enforce the auto-upgrade to HTTPS (which would break things). We have plans to replace the application in the longer term, but I'd like to be ahead of anything that will suddenly stop the application from working before then.</p>
  <p>Will using HTTP to localhost for images and other mixed content, as used in the scenario above, be an actual issue in the future?</p>