introduce
The browser's same-origin policy refers to a policy that restricts responses to requests whose request address is inconsistent with the request source, that is, if the server's response to a cross-origin request does not comply with the browser's same-origin policy specification, then The browser will not display the response content.
As long as one of the protocols , hosts , and port numbers of two URLs is different, they are regarded as different sources.
This involves a very important point, that is, the cross-origin request we sent did not reach the server, but the browser will decide whether to display the response content according to the relevant fields of the response header returned by the server .
For CORS- related fields, please refer to this article Cross-Origin Resource Sharing CORS Detailed Explanation , which introduces in detail how CORS-related fields affect the success of CORS requests in browsers.
It is worth noting that for GET , POST , and HEAD methods, even if the Access-Control-Allow-Methods in the response header does not include them, as long as the Access-Control-Allow-Origin field matches the origin of the request , it is also considered a budget The check request was successful. It can be seen that the three values of GET , POST , and HEAD are the default values of Access-Control-Allow-Methods , and setting the Access-Control-Allow-Methods field is just to add more allowed methods.
Browsers divide such cross-origin requests (CORS) into two categories: simple requests and complex requests .
simple request
For the definition of simple requests, refer to the MDN document , and those that do not meet the requirements are considered complex requests.
the difference
The difference between the two is that the preflight request (preflight) will not be sent before the complex request is sent . The purpose of the preflight request is that although the browser will not let it succeed for some CORS, it has indeed requested to the server, which may cause a deleted CORS request to the server if there is no preflight request, and Successfully affected, but the browser will not return the result of the response due to the same-origin policy. Therefore, before sending the actual CORS, the general browser will send a pre-check request to ask whether the server allows cross-origin, if not, it will not send the actual request, so as to avoid affecting the data of the server.
It should be noted that in the latest Chrome version, even a simple request, if the address it accesses is a private network, it will first initiate a preflight request, refer to private network access: introduce preflight request .
The document specifies when to access a private network, such as accessing a LAN in a public network, or accessing a local network (localhost) in a LAN.
As for why accessing the private network also needs to send a preflight request, it is because in this case, DNS rebinding attacks may occur . This article is a good introduction to the principle of DNS rebinding attacks: Detailed explanation of DNS rebinding attacks .
But in fact, if you think about it, you will find that the preflight request seems unnecessary. Because the server can completely judge whether to respond to the request based on the source of the CORS request. If the request does not meet the requirements, it can be rejected directly. There is no need for the browser to send a pre-check request first. This is indeed the case. For servers that already have protection against CORS , the preflight request is indeed redundant, but the same-origin policy of browsers appeared later, and servers before that did not prevent CORS, and they did not deliberately distinguish between The source of the request, but will respond to them all, then it will indeed cause the situation mentioned above, so the browser imposes various restrictions to protect this type of server. This is why it is said that the browser's same-origin policy is a gentleman's agreement, which only takes effect on the browser side.
You can take a look at this post: Why introduce a preflight request?
Cross domain in HTML tags
Many HTML tags can send requests, such as form forms, a tags, img tags, etc., but some will not be restricted, such as JSONP , which uses script tags to not be affected by cross-origin policies.
substance
I think the answer to this question is very good: why there is no cross-domain problem in form form submission, but there is a cross-domain problem in ajax submission?
The JS of one domain name cannot read the content of another domain name without permission. But browsers don't prevent you from sending requests to another domain name.