Iuri,
as often, you are quite fast in saying that some server is unable to something, etc. It usually helps to describe what you are trying to do, what your setup is, etc.
Concerning the OPTIONS preflight request: When you communicate via NGINX to the NaviServer, and NGINX does not forward the request to the backend, the backend has no chance to react. Talk directly to NaviServer to reduce complexity.
Concerning the log files: you compare the NGINX access.log with the NaviServer system log (error.log). When NaviServer receives the OPTIONS request, you will see an entry in the NaviServer access.log as well.
Concerning OPTIONS: Some OpenACS package register a OPTIONS handler, some do not. In case, the packages you have installed register no such handler, add to some of your packages to the tcl directory of your packages a *-init.tcl like the following:
optionshandler-init.tcl
ns_register_proc OPTIONS /REST/* ::my_options_handler
proc ::my_options_handler args {
ns_log notice "==== my_options_handler is called ==== "
ns_set put [ns_conn outputheaders] Allow "OPTIONS GET POST"
ns_return 200 text/plain {}
}
and test it e.g. with curl
$ curl -i -X OPTIONS http://localhost:8100//REST/test-header
HTTP/1.1 200 OK
Server: NaviServer/4.99.19
Date: Fri, 31 Jan 2020 08:42:26 GMT
Allow: OPTIONS GET POST
Content-Type: text/plain; charset=utf-8
Content-Length: 0
Connection: keep-alive
The response header field "Allow" was added by the handler. You will have to extend it if other HTTP methods should be allowed. My suspicion is that your react client does some CORS preflight requests. See e.g. [1] how to handle/avoid it.
-g
[1] https://stackoverflow.com/questions/29954037/why-is-an-options-request-sent-and-can-i-disable-it
