HTTPS is HTTP over Secure Socket Layer, a secure HTTP channel targeting, so there does not allow http requests on a page hosted HTTPS, in the event that prompted or given: ---
Mixed Content: The page at 'https://domain.com/w/a?id=074ac65d-70db-422d-a6d6-a534b0f410a4' was loaded over HTTPS, but requested an insecure image 'http://img.domain.com/images/2016/5/3/2016/058c5085-21b0-4b1d-bb64-23a119905c84_cf0d97ab-bbdf-4e25-bc5b-868bdfb581df.jpg'. This content should also be served over HTTPS.
Many operators no technical concepts to https, http resources can not help but appear in the data entered, the emergence of negligence and loopholes inevitable.
A way: CSP set upgrade-insecure-requests
W3C working group to consider upgrading to our hard HTTPS, in April 2015 out of the draft Insecure Requests an Upgrade (http://www.w3.org/TR/mixed-content/), his role is to make the browser automatically upgrade request. Join in our server's response headers:
server {
...
add_header Content-Security-Policy upgrade-insecure-requests;
...
}
Our page is https, and this page contains a large number of http resources (images, iframe, etc.), page once found the presence of the response headers will be automatically replaced with https http request when loading resources.
Method two: adding a page meta head:
<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests" />
This setting is also currently supports only chrome 43.0, but I believe, CSP will be the content of the future web front-end security concerns and vigorously use. The draft upgrade-insecure-requests will soon enter the RFC mode.
Original: Big Box Xie Guanlan personal learning website