Editor’s note: He Shijun (online name: Hax) is a senior front-end architect for 360. He has been active in the front-end and JavaScript community for more than a decade. Has made minor contributions to several Web standards, Groovy and indirectly Swift, and has participated in discussions on many new ECMAScript drafts in recent years. Designed and implemented Jedi languages and used in production environments, with a little hands-on experience in self-developed programming languages. He has been a QCon producer for three times and won the honor of “Excellent Producer”. He is also a frequent lecturer, guest and host at many other technical events.

CORS (Cross-origin Resource Sharing), cross-source resource sharing (commonly known as “cross-domain request”), we must have a basic understanding. If you don’t already know, you can read the introduction on MDN.

But are some friends surrounding CORS why CORS divided two requests into simple requests and preflighted requests?

If we look at the distinction between simple requests and prechecked requests, we can see that there are many conditions:

  • HTTP methods for simple requests can only be GET, HEAD, or POST
  • HTTP headers for simple requests can only be Accept/ accept-language/conent-language /Content-Type
  • Content-type headers for simple requests can only be Text /plain, multipart/form-data, or Application/X-www-form-urlencoded

It looks complicated.

So what to make of these limitations?

For example, if the method of the Form is specified as POST, you can use the encType attribute to specify how to encode the content of the Form. These are the three valid values.

A non-simple request is one that a normal HTML Form cannot implement. PUT methods, the need for other content encoding methods, custom headers, and so on.

For servers, first, many servers are not intended for cross-source use at all. Of course you don’t give CORS the response header and the browser doesn’t use the response result, but the request itself may have had consequences. It is best to disable cross-source requests by default.

Second, additional computational logic may be involved in answering whether a request is accepted across sources. The logic could be as simple as a blanket pass. It can also be complicated, depending on which resource and which operation comes from which Origin. For browsers, it’s as simple as whether a resource is allowed to cross sources. For servers, however, computing costs can vary. So we hope we don’t have to strain the server with every request.

Cers-preflight is a mechanism in which the browser makes a separate request first, asking the server if a resource can cross sources, and then not making the actual request if not. Note that permission before request disallows cross-source requests by default. If allowed, the browser remembers, sends the actual request, and then requests it directly each time without asking the server if it can cross the source. Therefore, if the server wants to support cross-source, all it has to do is calculate cross-source licenses for PreFlight. The actual response code itself doesn’t care about this at all. And because PreFlight is permissive, nothing needs to be done if the server does not intend to accept cross-sources.

But this mechanism can only be limited to non-simple requests. You cannot rely on cerS-preflight when handling simple requests if the server does not intend to accept cross-source requests. Because ordinary forms can make simple requests without CORS, disabling cross-sources by default is not possible.

In this case, there is no point in simply sending preflight. Even if sending preflight to the server does not save each subsequent calculation, instead, there is an extra preflight at the beginning.

Some people interpret simple requests that do not require Preflight as “backward compatibility.” That can’t be wrong. But strictly speaking, it is not “for the sake of downward compatibility”. In theory, browsers can discriminate between form requests and non-form requests — they do not issue Preflight for traditional cross-source form submissions, thus remaining compatible and only issue Preflight for non-form cross-source requests.

But it doesn’t do any good. It complicates things. For example, you could have scripted a normal cross-source request directly, and although you wouldn’t get a response (if the server doesn’t handle cross-source by default), your request might just be sent without a return, such as logging. But now you can’t do this if the server doesn’t understand preflight.

And if you do that, the server becomes the default to allow cross-source forms. If you want to control cross-source, you still have to (as usual) perform cross-source calculation logic directly in response processing; On the other hand, the server needs to add response support for preflight requests and perform similar cross-source computing logic to control the same cross-source requests from non-forms. Servers often don’t have the need to distinguish form/non-form differences, which is just a hassle for server-side engineers.

So simple requests don’t send PreFlight not because they are incompatible, but because sending preflight under compatible conditions doesn’t make sense for most server applications and complicates the problem.

About Weird Dance Weekly

Qiwu Weekly is a front-end technology community operated by qiwu Group, a professional front-end team of 360 Company. After paying attention to the public number, directly send the link to the background can contribute to us.