Closed jebos closed 3 years ago
@LucasRoesler what are your thoughts on this request?
@jebos thank you for using OpenFaaS. We will consider the request and get back to you.
I think this is a good start, it allows the user to handle the options request, which makes a lot of sense to me.
But it is important that it will not support CORS by itself. There are other headers that need to be included in the OPTIONS response, generally you need to response with allowed ORIGIN, METHODS, and HEADERS https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
Further the wildcard will not work for credentialed requests https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#Credentialed_requests_and_wildcards
When responding to a credentialed request, the server must specify an origin in the value of the Access-Control-Allow-Origin header, instead of specifying the "*" wildcard.
More generally, looking at the list of verbs https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods i think the only two i am not sure i see a usecase for are CONNECT and TRACE, we should probably support all of the others
@jebos feel free to contribute a PR to add the OPTIONS
method to the handler as you've suggested.
In case you want to connect your function to an external system, OPTIONS Verb is often used to provide informations about the ALLOWED ORIGIN. This is for example the case on Microsoft Azure IoT Hub using the Webhook with CloudEvents 1.0.
Expected Behaviour
OPTIONS Verb should be provided to handler.js
Current Behaviour
OPTIONS Verb is not provided to handler.js
Possible Solution
Add
app.options('/*', middleware);
to index.js of the template