javascript - Access-Control-Allow-Origin标头如何工作？(How does Access-Control-Allow-Origin header work?)

Question

Apparently, I have completely misunderstood its semantics.

(显然，我完全误解了它的语义。)

I thought of something like this:

(我想到了这样的事情：)

1. A client downloads javascript code MyCode.js from http://siteA - the origin .

   (客户端从http：// siteA- origin下载javascript代码MyCode.js。)

2. The response header of MyCode.js contains Access-Control-Allow-Origin: http://siteB , which I thought meant that MyCode.js was allowed to make cross-origin references to the site B.

   (MyCode.js的响应标头包含Access-Control-Allow-Origin：http：// siteB ，我认为这意味着MyCode.js被允许对站点B进行跨域引用。)

3. The client triggers some functionality of MyCode.js, which in turn make requests to http://siteB, which should be fine, despite being cross-origin requests.

   (客户端触发了MyCode.js的某些功能，该功能继而向http：// siteB发出了请求，尽管这是跨域请求，但仍然可以。)

Well, I am wrong.

(好吧，我错了。)

It does not work like this at all.

(它根本不像这样工作。)

So, I have read Cross-origin resource sharing and attempted to read Cross-Origin Resource Sharing in w3c recommendation

(因此，我阅读了跨域资源共享，并尝试阅读w3c建议中的跨域资源共享)

One thing is sure - I still do not understand how am I supposed to use this header.

(可以确定的一件事-我仍然不明白我应该如何使用此标头。)

I have full control of both site A and site B. How do I enable the javascript code downloaded from the site A to access resources on the site B using this header?

(我对站点A和站点B都拥有完全控制权。如何使用此标头使从站点A下载的javascript代码能够访问站点B上的资源？)

PS

(聚苯乙烯)

I do not want to utilize JSONP.

(我不想利用JSONP。)

  ask by mark translate from so

Answer 1

Access-Control-Allow-Origin is a CORS (Cross-Origin Resource Sharing) header .

(Access-Control-Allow-Origin是CORS（跨源资源共享）标头 。)

When Site A tries to fetch content from Site B, Site B can send an Access-Control-Allow-Origin response header to tell the browser that the content of this page is accessible to certain origins.

(当站点A尝试从站点B获取内容时，站点B可以发送Access-Control-Allow-Origin响应标头，以告知浏览器某些原始来源可以访问此页面的内容。)

(An origin is a domain, plus a scheme and port number .) By default, Site B's pages are not accessible to any other origin ;

(（ 来源是域，再加上方案和端口号 。）默认情况下， 其他任何来源都无法访问站点B的页面。)

using the Access-Control-Allow-Origin header opens a door for cross-origin access by specific requesting origins.

(使用Access-Control-Allow-Origin标头会打开一扇门，可以通过特定的请求来源进行跨域访问。)

For each resource/page that Site B wants to make accessible to Site A, Site B should serve its pages with the response header:

(对于站点B希望站点A可以访问的每个资源/页面，站点B应在其页面上提供响应标头：)

Access-Control-Allow-Origin: http://siteA.com

Modern browsers will not block cross-domain requests outright.

(现代浏览器不会完全阻止跨域请求。)

If Site A requests a page from Site B, the browser will actually fetch the requested page on the network level and check if the response headers list Site A as a permitted requester domain.

(如果站点A从站点B请求页面，则浏览器实际上将在网络级别获取请求的页面，并检查响应头是否将站点A列为允许的请求者域。)

If Site B has not indicated that Site A is allowed to access this page, the browser will trigger the XMLHttpRequest 's error event and deny the response data to the requesting JavaScript code.

(如果站点B未指示允许站点A访问此页面，则浏览器将触发XMLHttpRequest的error事件，并拒绝对请求JavaScript代码的响应数据。)

Non-simple requests(非简单请求)

What happens on the network level can be slightly more complex than explained above.

(什么发生在网络层面可以比上述解释稍微复杂一些 。)

If the request is a "non-simple" request , the browser first sends a data-less "preflight" OPTIONS request, to verify that the server will accept the request.

(如果该请求是“非简单”请求 ，则浏览器将首先发送一个无数据的“预检” OPTIONS请求，以验证服务器将接受该请求。)

A request is non-simple when either (or both):

(当一个（或两个）同时发生时，请求是不简单的：)

• using an HTTP verb other than GET or POST (eg PUT, DELETE)

  (使用GET或POST以外的HTTP动词（例如PUT，DELETE）)

• using non-simple request headers;

  (使用非简单的请求标头；)

  the only simple requests headers are:

  (仅有的简单请求标头是：)

  • Accept
  • Accept-Language
  • Content-Language
  • Content-Type (this is only simple when its value is application/x-www-form-urlencoded , multipart/form-data , or text/plain )

    (Content-Type （仅当其值为application/x-www-form-urlencoded ， multipart/form-data或text/plain时，这才简单）)

If the server responds to the OPTIONS preflight with appropriate response headers ( Access-Control-Allow-Headers for non-simple headers, Access-Control-Allow-Methods for non-simple verbs) that match the non-simple verb and/or non-simple headers, then the browser sends the actual request.

(如果服务器使用适当的响应标头（非简单标头的Access-Control-Allow-Headers ，非简单动词的Access-Control-Allow-Methods ）响应非简单动词和/或非匹配的OPTIONS预检响应-simple标头，然后浏览器发送实际请求。)

Supposing that Site A wants to send a PUT request for /somePage , with a non-simple Content-Type value of application/json , the browser would first send a preflight request:

(假设站点A要发送对/somePage的PUT请求，其非简单的Content-Type值为application/json ，则浏览器将首先发送预检请求：)

OPTIONS /somePage HTTP/1.1
Origin: http://siteA.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: Content-Type

Note that Access-Control-Request-Method and Access-Control-Request-Headers are added by the browser automatically;

(请注意，浏览器会自动添加Access-Control-Request-Method和Access-Control-Request-Headers 。)

you do not need to add them.

(您无需添加它们。)

This OPTIONS preflight gets the successful response headers:

(该OPTIONS预检获取成功的响应头：)

Access-Control-Allow-Origin: http://siteA.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: Content-Type

When sending the actual request (after preflight is done), the behavior is identical to how a simple request is handled.

(发送实际请求时（完成预检后），其行为与处理简单请求的方式相同。)

In other words, a non-simple request whose preflight is successful is treated the same as a simple request (ie, the server must still send Access-Control-Allow-Origin again for the actual response).

(换句话说，将预检成功的非简单请求与简单请求视为相同（即，服务器必须仍然为实际响应再次发送Access-Control-Allow-Origin ）。)

The browsers sends the actual request:

(浏览器发送实际请求：)

PUT /somePage HTTP/1.1
Origin: http://siteA.com
Content-Type: application/json

{ "myRequestContent": "JSON is so great" }

And the server sends back an Access-Control-Allow-Origin , just as it would for a simple request:

(然后服务器发送一个Access-Control-Allow-Origin ，就像处理一个简单的请求一样：)

Access-Control-Allow-Origin: http://siteA.com

See Understanding XMLHttpRequest over CORS for a little more information about non-simple requests.

(有关非简单请求的更多信息，请参阅通过CORS理解XMLHttpRequest 。)