从 HTTPS 页面访问 HTTP 图像源时来自 Chrome 87 的混合内容警告
Mixed-content warning from Chrome 87 when accessing HTTP image source from an HTTPS page
我们有一个在公司桌面上运行的内部 (.Net) 应用程序。它运行一个小型网络服务器，在 localhost 上的特定端口上侦听 HTTP 请求。我们有一个单独的 HTTPS 网站，通过将隐藏图像的 ImageUrl 设置为 URL 来与此应用程序通信 - 这会调用对 localhost 的 HTTP 请求，应用程序会获取该请求上和行动。例如本站会将图片的URL设置为：
http://127.0.0.1:5000/?command=dostuff
这是为了解决来自网站的任何类型的“混合内容”消息，因为图像似乎不受混合内容规则的约束。有点乱，但效果很好。
我看到 Chrome 正在朝着完全阻止页面上的混合内容的方向发展，果然 Chrome 87（目前处于测试通道）现在在控制台中显示这些警告：
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
https://blog.chromium.org/2019/10/no-more-mixed-messages-about-https.html
然而，尽管警告说请求正在自动升级，但它并没有自动升级 - 应用程序仍然收到普通 HTTP 请求并继续正常工作。
我找不到任何关于此警告是否为“软失败”以及 Chrome 的未来版本是否会强制自动升级到 HTTPS（这会破坏事情）的明确指导。我们计划在长期内替换该应用程序，但我希望在此之前能够避免突然停止该应用程序工作的任何事情。
使用 HTTP 到本地主机获取图像和其他混合内容（如上述场景中所使用的那样）将来会成为实际问题吗？
仔细阅读您的问题和所有评论 - 设身处地为您着想，我将执行以下操作：
- 既不干扰当前工作的 .Net app/localhost 服务器 (HTTP)，也不干扰 user-facing (HTTPS) front-end。
- 编写一个 simple/cheap 云函数（GCP Cloud Function 或 AWS Lambda）以从 front-end 中完全抽象出您的 .Net 应用程序。您当前的 HTTPS 应用程序只会调用云功能（HTTPS 到 HTTPS - 不必再祈祷 Google 不会 shut-down 混合流量，这最终会发生，尽管没人知道什么时候）。
- 云功能只是暂时将来自（不安全的）.Net 应用程序的 image/data 复制到云存储，然后通过 HTTPS 直接将其提供给您的 client-side。
此回答将重点关注您的主要问题：如上述场景中所用，将 HTTP 用于图像和其他混合内容的本地主机在未来会成为实际问题吗？
答案是是。
Update (April 6, 2020): Mixed image autoupgrading was originally scheduled for Chrome 81, but will be delayed until at least Chrome 84. Check the Chrome Platform Status entry for the latest information about when mixed images will be autoupgraded and blocked if they fail to load over https://.
该状态条目表示：
In developer trial (Behind a flag) (tracking bug) in:
Chrome for desktop release 86
Chrome for Android release 86
Android WebView release 86
…
Last updated on 2020-11-03
所以此功能已延迟，但即将推出。
我们有一个在公司桌面上运行的内部 (.Net) 应用程序。它运行一个小型网络服务器，在 localhost 上的特定端口上侦听 HTTP 请求。我们有一个单独的 HTTPS 网站，通过将隐藏图像的 ImageUrl 设置为 URL 来与此应用程序通信 - 这会调用对 localhost 的 HTTP 请求，应用程序会获取该请求上和行动。例如本站会将图片的URL设置为：
http://127.0.0.1:5000/?command=dostuff
这是为了解决来自网站的任何类型的“混合内容”消息，因为图像似乎不受混合内容规则的约束。有点乱，但效果很好。
我看到 Chrome 正在朝着完全阻止页面上的混合内容的方向发展，果然 Chrome 87（目前处于测试通道）现在在控制台中显示这些警告：
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 https://blog.chromium.org/2019/10/no-more-mixed-messages-about-https.html
然而，尽管警告说请求正在自动升级，但它并没有自动升级 - 应用程序仍然收到普通 HTTP 请求并继续正常工作。
我找不到任何关于此警告是否为“软失败”以及 Chrome 的未来版本是否会强制自动升级到 HTTPS（这会破坏事情）的明确指导。我们计划在长期内替换该应用程序，但我希望在此之前能够避免突然停止该应用程序工作的任何事情。
使用 HTTP 到本地主机获取图像和其他混合内容（如上述场景中所使用的那样）将来会成为实际问题吗？
仔细阅读您的问题和所有评论 - 设身处地为您着想，我将执行以下操作：
- 既不干扰当前工作的 .Net app/localhost 服务器 (HTTP)，也不干扰 user-facing (HTTPS) front-end。
- 编写一个 simple/cheap 云函数（GCP Cloud Function 或 AWS Lambda）以从 front-end 中完全抽象出您的 .Net 应用程序。您当前的 HTTPS 应用程序只会调用云功能（HTTPS 到 HTTPS - 不必再祈祷 Google 不会 shut-down 混合流量，这最终会发生，尽管没人知道什么时候）。
- 云功能只是暂时将来自（不安全的）.Net 应用程序的 image/data 复制到云存储，然后通过 HTTPS 直接将其提供给您的 client-side。
此回答将重点关注您的主要问题：如上述场景中所用，将 HTTP 用于图像和其他混合内容的本地主机在未来会成为实际问题吗？
答案是是。
Update (April 6, 2020): Mixed image autoupgrading was originally scheduled for Chrome 81, but will be delayed until at least Chrome 84. Check the Chrome Platform Status entry for the latest information about when mixed images will be autoupgraded and blocked if they fail to load over https://.
该状态条目表示：
In developer trial (Behind a flag) (tracking bug) in:
Chrome for desktop release 86
Chrome for Android release 86
Android WebView release 86
…
Last updated on 2020-11-03
所以此功能已延迟，但即将推出。