The OPTIONS HTTP method requests permitted communication options for a given URL or server. This can be used to test the allowed HTTP methods for a request, or to determine whether a request would succeed when making a CORS preflighted request. A client can specify a URL with this method, or an asterisk (*) to refer to the entire server.
i.e. I want to test for an endpoint and not use GET or POST but the OPTIONS verb to. My workaround is to use the PATCH verb but that's incorrect.
NR already handles OPTIONS method for "*" for the CORS settings - which means adding OPTIONS HTTP-In nodes were not handled. The was overcame by checking which routes are setup for OPTIONS method within the options handler & calling next() or corsHandler appropriately
Nicks comment on the PR:
I'm not sure this is going to quite work as intended.
The route path could be parameterised (/foo/:id) in which case you can't do a simple string compare with the request path. It also is quite an overhead to iterate over all the paths to find matches with every request.
A different approach would be to ensure the corsHandler is kept at the end of RED.httpNode._router.stack - so it acts as a catch-all in case no HTTP-In node gets there first. Its hacky as _router.stack is an internal of express... but I can't see how else to do this efficiently.
So because OPTIONS is already handled somewhere in NR, this isn't as simple as the other verbs? Which seems non-obvious to me since the other verbs are also part of what NR handles. I mean, can't the options handler as defined in the settings be put at the end of the handler chain or because flows are dynamic and http-in can be defined anywhere, there really isn't a end to the handlers?
But even that seems to be managed by all the other verbs. Since the http-in nodes live in the same request-handler code as NR itself, I can define a http-in that overwrites the builtin editor requests (if I so wanted). There isn't any scoping on incoming requests, so there is no difference between a editor request and any other request to the NR backend defined by a http-in.
So the risk of overwriting corsHandlers defined in settings.js is just as present for all other requests. If I understand the issue correctly.
For me it also seems non-obvious why corsHandlers are defined in settings.js instead of being part of the flows defined in NR itself. I guess this was a historical choice which is now backward compatibility - fair enough, I guess.
Not only that. The same Express web server is also used by other contributed nodes that serve to end users. Because of the way that Express works, it is all too easy to end up with overlapping URL paths dealt with by different handlers. Even more confusing when you realise that, by default, Node-RED does not define a URL path separation between the Editor (admin Express server) and user-facing paths. Express doesn't make this easy either since it is quite hard to extract defined URL paths and their handling functions (which is why I build a manual catalogue as UIBUILDER starts up).
This is, I think, where Node-RED's flexibility and resulting complexity works against it.
Unfortunately, I can't comment directly on the issue of the OPTIONS verb since I don't know the details of how it is used in core. It probably requires someone to set up a set of test cases to validate the current use and then to check against various different scenarios with the suggested addition?
