Access-Control-Allow-Origin called header
When a site X attempts to access content from another site, the requesting site (site X) may send a
Access-Control-Allow-Origin response header to tell the browser that the content of this page is accessible to certain sources.
By default,
site pages are not accessible to other sources ; using the
Access-Control-Allow-Origin header opens a port for cross-source access by requesting specific sources.
For each feature / page that Site Y wants to make accessible to site X, Site Y should serve its pages with the response header:
Access-Control-Allow-Origin: http://siteX.com
Modern browsers will not block cross-domain requests. If Site X requests a Site Y page, the browser will actually access the requested page and check the Site X response headers as an allowed requesting domain. If Site Y has not indicated that Site X is allowed to access this page, the browser will trigger an error event in XMLHttpRequest and deny the response data to the requesting JavaScript code.
Non-Simple Orders
What happens at the network level may be a bit more complex than explained above. If the request is a non-simple request < a>, the first browser sends a "pre-print" OPTIONS request, to verify that the server will accept the request. An application is considered "non-simple" when one or both situations:
If the server responds to the test options with appropriate response headers ( Control-Allow-Headers for non-simple headers and Access-Access-Control-Allow-Methods for non-simple methods) that correspond to the "non-simple" method and / or "non-simple" headers, then the browser sends the actual request.
Assuming that Site X wants to send a PUT request to /SomePage , with a Content-Type non-simple value of application/json , the browser first sends a request for verification:
OPTIONS /SomePage HTTP/1.1
Origin: http://siteX.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; you do not need to add them. This proof OPTIONS receives the successful response headers:
Access-Control-Allow-Origin: http://siteX.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: Content-Type
When submitting the actual request (after proof is made), the behavior is identical to the way a simple request is handled. In other words, a "non-simple" request whose receipt is successful is handled in the same way as a simple request (ie the server should still send Access-Control-Allow-Origin back to the actual response).
Browsers send the actual request:
PUT /SomePage HTTP/1.1
Origin: http://siteX.com
Content-Type: application/json
{ "myRequestContent": "JSON is so great" }
And the server sends back Access-Control-Allow-Origin , just as it would for a simple request:
Access-Control-Allow-Origin: http://siteX.com
See XMLHttpRequest Understanding on CORS for a little more information on non-simple requests.
Source: apsillers
