Does inets and httpd support OPTION requests and why can't my custom module add this functionality?

Hi Everyone!

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.

Kind Regards


1 Like

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).

There are some other problems with httpd: No support for multiple headers and No cookie support in standalone mode, these might save your time in the future.

Would like to hear from OTP team, I’m interested in collaborating if someone can say whether this should be solved or not.


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.