Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

We need to upgrade and secure the HTTP servers backing the JSON-RPC and Prometheus end-points #358

Open
zah opened this issue Jul 19, 2019 · 3 comments

Comments

@zah
Copy link
Member

commented Jul 19, 2019

Currently, out JSON-RPC server is based on Chronos, but offers only HTTP 1.0 compatibility.

The Prometheus server runs in a separate thread and uses asyncdispatch form Nim's standard library. It's based on the asynchttpserver module, which has a number of short-comings:

https://github.com/nim-lang/Nim/blob/devel/lib/pure/asynchttpserver.nim#L12-L15

For more in-depth discussion, please see this thread:
#352

We need to develop a production-ready server that we'll be able to use for both end-points (potentially from a single thread).

@stefantalpalaru

This comment has been minimized.

Copy link
Contributor

commented Jul 19, 2019

Currently, out JSON-RPC server is based on Chronos, but offers only HTTP 1.0 compatibility.

That wouldn't have been a problem. It only supports the "application/json" content type: https://github.com/status-im/nim-json-rpc/blob/de05184c740095a2f3f6f61ff90e5aed0e83d5d8/json_rpc/servers/httpserver.nim#L76

@dom96

This comment has been minimized.

Copy link

commented Aug 5, 2019

Have you guys considered spending time improving the asynchttpserver in the stdlib to make it production-ready? It likely won’t involve much effort and would help out the Nim community significantly.

@arnetheduck

This comment has been minimized.

Copy link
Member

commented Aug 5, 2019

Have you guys considered spending time improving the asynchttpserver in the stdlib to make it production-ready? It likely won’t involve much effort and would help out the Nim community significantly.

we welcome the community to port the changes and improvements we develop, or alternatively remove asynchttp from std lib into a separate library and take it from there.

as discussed at length and many times, our goals for chronos differ from those of the std lib significantly, as does the development model.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.