tracker issue : CF-4197164

select a category, or use search below
(searches all categories and all time range)

CORS Preflight unable to be caught by Application.cfc onRequestStart function. Uses built-in jersey handler instead.

| View in Tracker

Status/Resolution/Reason: To Fix//EnhancementRequired

Reporter/Name(from Bugbase): Mosh Teitelbaum / Mosh Teitelbaum (Mosh Teitelbaum)

Created: 10/31/2016

Components: REST Services

Versions: 2016,11.0,2018

Failure Type: Incorrect w/Workaround

Found In Build/Fixed In Build: CF2016_Update3 /

Priority/Frequency: Normal / All users will encounter

Locale/System: English / Windows 10 64 bit

Vote Count: 0

Problem Description:
When the client source code originates from a different source as the server on which the REST API code resides, modern browsers send a CORS preflight request to validate that the server allows client requests from Cross-Origin sources.  The CORS preflight request is simply an OPTIONS request to the exact same URI as what is supposed to be requested with two headers, Access-Control-Request-Method (whose value is the HTTP method that is about to be requested) and Access-Control-Request-Headers (which lists the headers that will be sent with the request).  The server, if Cross-Origin requests are allowed, must respond with several CORS-specific headers to let the client know that such requests are OK.

If a requested endpoint does not have a handler defined for the OPTIONS http method, ColdFusion relies on jersey's default OPTIONS handler which sends back some XML (in WADL format) that documents that options available at the requested endpoint.  This functionality is documented at . This is great for self-documentation but horrible as far as exposing internals and for supporting CORS preflight checks.

There are two problems here:
1) There does not appear to be any way to turn off the jersey default response to such a request.  In the jersey documentation linked to above, there is an option to disable this functionality (see section 17.2. Configuration) via the following:
However, I have not been able to find a CF equivalent.

2) Ideally, instead of having to define OPTIONS handlers in every endpoint of the API, it would be nice to include some code in the API's Application.cfc onRequestStart() method to check if the request uses the OPTIONS method and includes the CORS-specific headers.  If so, call some CORS-specific functionality and if not, allow the request to proceed as normal.  Unfortunately, if an OPTIONS handler is not defined for that endpoint, onRequestStart() never gets called.

Steps to Reproduce:
1) Define an endpoint and do not include a handler for the OPTIONS method.
2) Request that endpoint using the OPTIONS method.
3) In application.cfc::onRequestStart(), include some code to check for requests using the OPTIONS method and try to handle it.  You won't be able to and will, instead, continue to get the jersey WADL response.

Actual Result:
Jersey WADL

Expected Result:
Whatever you define should happen in onRequestStart()

Any Workarounds:
Create OPTIONS handlers for every endpoint of your API.

----------------------------- Additional Watson Details -----------------------------

Watson Bug ID:	4197164

External Customer Info:
External Company:  
External Customer Name: Mosh Teitelbaum
External Customer Email:  
External Test Config: My Hardware and Environment details:

ColdFusion 2016 Enterprise

Windows Server 2012