Pre-flight Check

A CORS aware client attempting to make a cross-origin request first issues a pre-flight check to the resource it is attempting to access. This is an OPTIONS request containing an Origin header populated with the location which is originating the request and an "Access-Control-Request-Method" header indicating which method the real request uses. This request might optionally contain an "Access-Control-Request-Headers" header indicating any additional headers included in the request.

An example pre-flight request:

A successful pre-flight request results in the web reverse proxy returning an empty response with HTTP status code 204. Additionally, the response contains headers which indicate to the client what is acceptable in is cross-origin requests. An example pre-flight response:


Pre-flight Check Processing

The web reverse proxy CORS policy includes the following entries related to CORS pre-flight requests:

The request-match, allow-origin, and allow-credentials entries are also used when processing regular cross-origin requests. The handle-pre-flight entry controls whether or not the web reverse proxy responds to pre-flight requests.

When set to false, pre-flight requests are forwarded to the back-end application like a normal request. When set to true, the web reverse proxy performs CORS processing and generates a pre-flight response without contacting the back-end application.

The processing described in Process Common to Pre-Flight Check and Regular Cross-Origin Requests takes place before the processing described that follows.


Evaluating Access-Control-Request-Method

The first step performed by the web reverse proxy when performing a pre-flight check is to evaluate if the method provided in the requests Access-Control-Request-Method header is permitted. The web reverse proxy indicates to clients which methods are permitted using the Access-Control-Request-Method header.

If no methods are configured, the web reverse proxy allows any method and returns the value provided by the client in the Access-Control-Request-Method header. If any methods are configured, the method is evaluated against the list of configured methods (see allow-method) and list of simple methods (see Simple Methods and Headers) to determine if it is permitted. If the method is permitted, the reverse proxy returns to the client a list of all allowed methods in the Access-Control-Request-Method header.


Evaluating Access-Control-Request-Headers

The list of headers indicated by the client is also checked to ensure they are valid according to the configured policy. The web reverse proxy indicates to clients which headers are acceptable using the Access-Control-Request-Headers header.

If no headers are configured, the web reverse proxy allows any headers and returns the value provided by the client in the Access-Control-Request-Headers header. If any allowed headers are configured, the headers are evaluated against the list of configured allowed headers (see allow-header) and list of simple headers (see Simple Methods and Headers) to determine if they are permitted. If all of the methods present in the request are permitted, the web reverse proxy returns to the client a list of all allowed headers in the Access-Control-Request-Headers header.