Congrats on shipping! This project looks very interesting already and will hopefully pick up more contributors.
Is there already support for configuration files? Because for me the performance isn't the most important issue, in fact the main reason I'm using nginx over Apache is that I don't want to deal with .htaccess any more.
I think if you would consider adding support for the nginx config file format to H2O, thus making it a drop-in replacement for it (if all the used features are actually supported), you could give the project a huge boost.
Unfortunately they are not compatible with that of Nginx. I do not think it is possible to take such approach considering the differences in the internals of both servers.
nginx' configuration format leaves a lot to be desired, as evidenced by the (former, hopefully) widespread use of exploitable php calls.
There are also if directives in there, but they don't really work they way you think. You really need a deep understanding of its parsing rules in order to do anything remotely complicated with it. It's certainly possible to do better.
(Please don't mention Apache here and its steaming pile of faux-xml. Existence of worse does not make better.)
Interesting article. And congratulations for the release!
Sorry this is a bit off-topic (and doesn't apply to H2O as it's been in the works for a while looking at the commits), but I wonder, today, with a language like Rust (1.0 is at the door [1]), as performant as its safe C equivalent but modern and safe by design (and with an escape hatch to C/C++ if needed), what would be the advantages of starting a long term project of this type in C today?
And even if it was, it would take 3-5 years until it gets any decent adoption (if that happens, which remains to be seen). It doesn't even have Go level adoption yet, and Go's adoption is not something to write home about either.
C, people know very well, has tons of tooling, plays well in all platforms and has all the libraries in the world available for it.
> Go's adoption is not something to write home about either.
I wouldn't say so... Go may not be as widespread as other older languages, but the speed at which it's taking over new developments (and sometimes re-writes) can't be glossed over that easily.
Regarding GP's comment, I believe the number 1 argument why that project is started in C is performance. Even nginx, which is also written in C, can't match H2O's speed; I doubt Rust with all the micro-management you can have could beat this level of dedication towards performance.
Looking at the tangentially linked qrintf project that H2O uses ( https://github.com/h2o/qrintf ), replacing generic sprintf calls with specialised versions for a 10x speed boost - that seems like a brilliant idea, I wonder why it took so long for somebody to think of it?
People have thought of it -- there's probably just not that many applications where sprintf is a bottleneck. Especially enough of a bottleneck to justify a code gen tool.
The OCaml community, and probably others, have noted that printf is an embedded DSL and treat it as something to be compiled rather than interpreted.
Rust borrows heavily from OCaml, and uses compile time macros for printf and regex, i.e. format! and regex! (the trailing ! means it's a macro that can be further compiled by the compiler).
One of the problems with compiling print/scanf is that a lot of the overhead comes from locale handling, which is a runtime variable. Parsing is fairly negligible for short format strings.
> Instead, switching back to sending small asset files for every required element consisting the webpage being request becomes an ideal approach
This doesn't solve the other side of the problem that spritesheets are meant to solve, namely that an individual image will not be loaded yet when the first UI element using it is displayed (e.g. in a CSS rollover, or new section of a SPA appears). I can't see a way that new protocols are going to solve this, unless I'm missing something in how HTTP2 is going to be handled by the browser?
I assume that once you're forced to preload everything you might need for the page, it's no longer more efficient to break up into multiple tiny requests.
good point. I imagine determining when to push these assets will become a complex choice though.
Also, I realized shortly after commenting that I missed the obvious benefit of avoiding downloading global spritesheets and other compiled assets for individual pages that only use a subset of the content.
Obviously it's great software. Does Kazuho work alone on this ? If it's meant to replace nginx, it needs a lot of other options/functions/extensions/modules/...
Socket API is a bottleneck now, right?
So, next step: roll your own http-friendly tcp stack on top of netmap/dpdk and get 10x performance increase over nginx.
I am not so much into web-servers (yet), but I found this in the feature list:
reverse proxy
HTTP/1 only (no HTTPS)
Are there any plans to add also HTTPS-support for reverse proxy? Since I have to include a secondary (Tornado) web-server unto my stack for dynamic pages.
It also puzzled me, that https is not supported, but in the benchmarks I found a part: "HTTPS/2 (reverse-proxy)". As I said, I am not so much in Web-servers and https/2, but that was a little confusing.
HTTP and HTTPS (both version 1 and 2) are supported for downstream connections (i.e. connection bet. H2O and web browsers).
Only plain-text HTTP/1 is supported for upstream connections (connection bet. H2O and web application servers).
Don't be afraid to not add features. I'd love to see something like this stay as a very high speed server, especially with the move towards single-page static apps that connect to restful services.
Can I than use H2O to connect to a web-browser via HTTPS and H2O is routing the same request upstream via HTTP to a web application server? (that of course would suffice for me).
Is it really the same (really asking)?? Sometimes there are subtle protocol changes, when something is standardized -- and as much I understand, HTTP/2 took a while ...
the initial http 2.0 draft was just a copy of spdy (in nov 2012). There have been changes to 2.0, so they aren't exactly the same.. but http 2.0 is meant to completely replace spdy.
Any of the servers/clients that support spdy currently will eventually make the minor changes, and call it http 2.0.