Cross-Origin Resource Sharing

Cross-Origin Resource Sharing (CORS) is a standard for permitting web pages to access content that is hosted on other domains.

A web page can make requests to access other content, where that content is either hosted on the same domain or another domain. A web page can request static content, such as an image, JavaScript, or CSS file. Additionally, a web page can make a request for dynamic content, such as making a request to a REST API.

When these requests are made, the origin of the web page and the origin of the content that is being requested are compared. The origin is a combination of the scheme, host name, and port number. For example, the origin of https://mydomain.com:7843/path/to/index.html is https://mydomain.com:7843

When the origins of the web page and the content that is being requested match, the request is always permitted. When the origins match, it is called a same-origin policy. However, when the origins do not match, a cross-origin request must be made.

When a cross-origin request is made, the server that is hosting the content that is being requested must permit the web browser that is displaying the web page to make the request. If the server does not permit the web browser to make the request, the request is rejected. The CORS specification describes the mechanism that allows the server to permit the web browser access to content that the server is hosting. For more information about CORS, see Cross-Origin Resource Sharing.

Two types of request are defined in the CORS specification:
Simple request
If the HTTP method of the request is GET, HEAD, or POST and the request includes only a specific set of HTTP headers, a web browser makes a simple request. When a simple request is made, the request is sent to the server as a normal request. If the server is configured to permit the request, additional HTTP headers are included in the response. If those headers are not present in the response, the web browser drops the response and passes an error back to the web page.
Preflight request
If the request does not meet the requirements of a simple request, a web browser makes a preflight request. A web browser makes a preflight request in two parts: a preflight request and an actual request. The first request, the preflight request, determines whether the server permits the actual request. If the server permits the actual request, additional HTTP headers are included in the response to the preflight request. If the headers are present, the web browser makes the actual request to the server. If those headers are not present in the response to the preflight request, the web browser drops the response and passes an error back to the web page.

To enable a web page that is running on a separate origin to access HTTP services (for example, an HTTPInput node in a message flow) that are being hosted on IBM® Integration Bus, you must enable CORS. If a simple request is made, the HTTPInput node that is listening on that URL is called when it receives the request and processes the request normally, regardless of whether IBM Integration Bus is configured to permit the request. If a preflight request is made, the HTTPInput node that is listening on that URL is not called when it receives the preflight request. The node is called only if IBM Integration Bus is configured to permit the request, and it is called only when the web browser makes the actual request.

IBM Integration Bus must be configured to allow cross-origin requests. CORS is disabled by default. For more information, see Permitting web browsers to access deployed HTTP services by enabling Cross-Origin Resource Sharing.