I should have come here 3 days ago but my stubborn nature thought I could scrum inets and httpd into submission by myself.
What I’m trying to do:
I need to run several small HTTP servers each as a branch of a larger process tree and therefore inets has always been my go-to.
Recently I wanted to upgrade from just using GET requests with the mod_esi functionality to POST requests where I can add a body and some JSON.
The problem
Modern Browsers do a pre-flight OPTIONS request before doing POST requests as part of CORS.
I have written my own httpd module (mod_help_me_cors_pls) where I export the function do(ModData) as the other httpd modules do. Now I can catch all HTTP requests I want as I want EXCEPT for “OPTIONS” requests? The inets server still throws a 501 not_supported error. Does it check for the request type even before calling the mod_something:do callback?
Can anyone please tell me how I could use inets and httpd with a custom httpd module to handle POST, PUT, OPTIONS and other requests?
I don’t want to manually disable CORS in the browser
I would like to avoid libraries such as cowboy and yaws.
By looking at source, httpd_request_handler:handle_http_msg/2 will call httpd_request:validate/3 which will return an error, resulting in status 501 being returned to the client. I think this is happening before using any of your modules so that is why you can’t implement a handler module.
Maybe there is some implementation issue with this method. I see that method CONNECT is also missing in the httpd_request:validate/3 clauses, even though it exists in HTTP 1.1.
FWIW: OPTION is supported in httpc, and CONNECT is missing in both httpd and httpc (actually, CONNECT is used internally in httpc, but is not allowed for calling through httpc:request/5).
Amazing, thank you!
I wish it would just throw whatever it can’t handle to us. I understand that I’ll be re-implementing some functionality that exists in cowboy or other server libraries, I just don’t want the whole arsenal if I’m completely in control of what the client will send.
Most of the httpd implementation is fairly ancient. I think that the OPTIONS method was not implemented and thereby rejected early. Although httpd is not super prioritized it is used as a simple embedded server and I think we should aim to improve it as such and gradually remove legacy things not that useful.
When it comes to httpc I think standalone mode should be totally dropped and if you want to improve something the pipeline/keepalive session selection should be rewritten so that is less of a bottleneck which sort of justified the ugly standalone hack.