Nginx Configure Cross-domain Request Access-control-allow-origin *

When a 403 Cross-domain error occurs, the No ' Access-control-allow-origin ' header is present on the requested resource needs to be configured with the header parameter of the response for the Nginx server: First, the solution

You only need to configure the following parameters in the Nginx configuration file:

Location/{  
  add_header access-control-allow-origin *;
  Add_header access-control-allow-headers "Origin, X-requested-with, Content-type, Accept";
  Add_header access-control-allow-methods "Get, POST, Options";

The above configuration code can solve the problem, do not want to further study, see here on the =-= II, Interpretation 1. Access-control-allow-origin

The server is not allowed to cross domains by default. Configuring Access-control-allow-origin * For the Nginx server indicates that the server can accept all request sources (Origin), that is, accept all cross-domain requests. 2. The access-control-allow-headers is designed to prevent the following errors from occurring:

Request header field Content-type is isn't allowed by access-control-allow-headers in preflight response.

This error indicates that the current request Content-type value is not supported. In fact, we initiated the "Application/json" type request caused. Here is a concept: pre-inspection requests (Preflight request), please see the following "Pre-inspection Request" introduction. 3. The access-control-allow-methods is designed to prevent the following errors from occurring:

Content-type is isn't allowed by access-control-allow-headers in preflight response.

The method options are required to send a "pre-check request", so the server needs to allow this method. III. Pre-inspection requests (Preflight request)

In fact, the above configuration involves a standard of the global Consortium: Cros, the full name is Cross-domain resource sharing (cross-origin resource sharing), it is proposed to address cross-domain requests.

The cross-domain resource sharing (CORS) standard adds a set of HTTP header fields that allow the server to declare which source stations have access to which resources. In addition, the specification requires that for HTTP request methods that may have side effects on server data (in particular, HTTP requests other than GET, or POST requests with certain MIME types), the browser must first initiate a pre-check request using the Options method (pre Flight request) To learn whether the service side allows the Cross-domain requests. The actual HTTP request is not initiated until the server confirms the permission. In the return of the prefetch request, the server side can also notify the client whether it needs to carry credentials (including Cookies and HTTP authentication related data).

In fact, the Content-type field type of Application/json request is the above with some MIME type of POST request, cors, Content-type does not belong to the following MIME type, is a pre-check request:

application/x-www-form-urlencoded
multipart/form-data
text/plain

So Application/json's request will add a "pre-inspection" request before formal communication, and this time the "pre-test" request will take a header message Access-control-request-headers:content-type:

Options/api/test http/1.1
origin:http://foo.example
access-control-request-method:post
Access-control-request-headers:content-type ...
Omitted a few

When the server responds, the header information returned if it does not contain access-control-request-headers:content-type means that the Non-default Content-type is not accepted. The following error is present:

Request header field Content-type is isn't allowed by access-control-allow-headers in preflight response.