-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Goal of powering a nginx-like proxy with hpyer #769
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
Comments
hyper is more than a parser. The parsing part is handled by https://github.com/seanmonstar/httparse, which was modeled after picohttpparser. hyper also aims to handle a lot of the semantics of http1/2. It is not itself going to be a competitor to h2o or nginx. Rather, it will power any competitors, along with any other sorts of servers that aren't reverse proxies. I've been working on a reverse proxy project that uses the async hyper, and I've spent many a evening reading h2o or nginx source code to see what lessons I can learn. I don't have a working project that I can commit to a repo just yet, as I want to also release async hyper soon. I've been working on the proxy as a sort of "drive the async work" effort. Once I have released async hyper, I can work more on the specific parts of a proper reverse proxy: configuration, various directives like headers, files, directories, proxy, and so forth. |
That's a great answer - thank you for elaborating. If you'd like some early testing for your proxy based on the mio branch, let me know, I'll give it a spin. |
Btw, I just came across this on hacker news yesterday, you might find it interesting: http://natsys-lab.blogspot.de/2014/11/the-fast-finite-state-machine-for-http.html |
Closing as there isn't really anything actionable for hyper here. |
This question builds on #320 and #395 (comment)
I do not see hyper as being a direct competitor to either nginx or h2o, but rather as an http parser powering a potential competitor. In that light, it is more similar to something like https://github.com/h2o/picohttpparser, which powers h2o.
What I'd like to ask is how far away is hyper from this goal, and is there anything left to learn from nginx's http parser and picohttpparser, other than using aio and SIMD? Maybe reusing allocations or pooling them in an arena for the request lifetime and destroying them in one go?
Just for completeness, there is a somewhat newer presentation on h2o than what was posted in #320 that might be interesting:
http://www.slideshare.net/kazuho/h2o-making-http-better
The text was updated successfully, but these errors were encountered: