Difference between revisions of "Origin Access Control"
(→References) |
(→Context) |
||
Line 45: | Line 45: | ||
</pre> | </pre> | ||
See [https://stackoverflow.com/a/13400954/710446 Understanding XMLHttpRequest over CORS] for a little more information about non-simple requests. | See [https://stackoverflow.com/a/13400954/710446 Understanding XMLHttpRequest over CORS] for a little more information about non-simple requests. | ||
+ | ===Taxonomy=== | ||
+ | '''HTTP response data''' is the data sent by a server to a client in response to an HTTP request. It contains information about the status of the request and may also contain the requested content in its body. The response data is usually sent in the form of a message, which includes a status code and a status message1. The status code is a three-digit number that indicates the status of the request, such as whether it was successful or not. The status message is a short description of the status code.<ref>Mozilla, ''HTTP response status codes'' https://developer.mozilla.org/en-US/docs/Web/HTTP/Status</ref> | ||
==References== | ==References== |
Revision as of 14:20, 27 January 2024
Full Title or Meme
Access-Control-Allow-Origin is a CORS (cross-origin resource sharing) header.
Context
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. (An origin is a domain, plus a scheme and port number.) By default, Site B's pages are not accessible to any other origin; using the Access-Control-Allow-Origin header opens a door for cross-origin access by specific requesting origins.
For each resource/page that Site B wants to make accessible to Site A, Site B should serve its pages with the response header:
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. 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. 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. A request is non-simple when either (or both): using an HTTP verb other than GET or POST (e.g. 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) 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. 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: 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; you do not need to add them. This OPTIONS preflight gets the successful response headers: 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 (i.e., the server must still send Access-Control-Allow-Origin again for the actual response). 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: http://siteA.com
See Understanding XMLHttpRequest over CORS for a little more information about non-simple requests.
Taxonomy
HTTP response data is the data sent by a server to a client in response to an HTTP request. It contains information about the status of the request and may also contain the requested content in its body. The response data is usually sent in the form of a message, which includes a status code and a status message1. The status code is a three-digit number that indicates the status of the request, such as whether it was successful or not. The status message is a short description of the status code.[1]
References
- from stack overflow with lots of germane responses.
- See wiki page on Cross-Origin iFrame