Generic HTTP OPTIONS handler overrides options handler in controller

[ComLock]

In a cross site situation CORS headers needs to be added on the "pre-flight" OPTIONS request in order for a normal fetch to work: https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API

I have found no way of doing this in Enonic XP.

In my usecase it's a service, but this should apply to all controllers.

I've tried implementing exports.handle exports.handleOptions exports.options

I've tried filters, but they don't apply to services even though applyFilters=true.

Filters probably don't even apply to an OPTIONS request.

I've heard Enonic XP currently has its own default handling of OPTIONS requests. Perhaps it should be possible to override or extend it. Response filters...

Or maybe CORS could be handeled in a more graceful way so that the default OPTIONS handling could implement it too.

[ComLock]

There is a workaround with fetch by making the request simple so that the OPTIONS request gets skipped.

https://stackoverflow.com/questions/29954037/why-is-an-options-request-sent-and-can-i-disable-it

[mortyeriksen]

Alex, can you check if this is bug?

[aro]

I think it is a bug. It should be possible to override the default OPTIONS handling by exporting an options function in the controller.

exports.options = function(req) { }

[sigdestad]

So "OPTIONS" is an http method.. Did not know. Let's fix it :-) Do we have a hardcoded list of mappings from "METHOD" to "export.xx" then?

[aro]

It's not hardcoded. We take the HTTP request method and look for it as a export function. I think the problem is that the default OPTIONS handler in portal overrides the execution of the exports.option from controller. But we need to check that.