Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Initial release of H2O, and why HTTPD performance will matter in 2015

blog.kazuhooku.com

Post reply on HN
Print view View original

41–50 of 85 posts

Re: Show HN: Initial release of H2O, and why HTTPD performance will matter in 2015

#41

Post by meowface »

xorcist wrote: post #9
rkrzr wrote: post #2

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, thu…

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 steam…

>nginx' configuration format leaves a lot to be desired, as evidenced by the (former, hopefully) widespread use of exploitable php calls.

This has nothing to do with nginx's config format at all. It's simply a vulnerability in FastCGI for PHP and the way PHP file paths are passed.

Re: Show HN: Initial release of H2O, and why HTTPD performance will matter in 2015

#42

Post by meowface »

lonnyk wrote: post #38
xorcist wrote: post #9

Earlier quoted context omitted.

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 steam…

> as evidenced by the (former, hopefully) widespread use of exploitable php calls Could someone elaborate on what this is referring to?

Read through https://nealpoole.com/blog/2011/04/setting-up-php-fastcgi-an...

Re: Show HN: Initial release of H2O, and why HTTPD performance will matter in 2015

#43

Post by nathan7 »

stephth wrote: post #20

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 p…

I'm writing an HTTP reverse proxy in Rust, and my main gripe so far is that I have to roll my own async I/O. Binding node's HTTP parsers over is going well, but also takes a bunch of effort. Safe-by-design and close to the metal are proving very enjoyable to work with for this, however.

Re: Show HN: Initial release of H2O, and why HTTPD performance will matter in 2015

#45

Post by ncallaway »

robbles wrote: post #18

> 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…

I would consider continuing to spritesheet the button itself. The main difference is that each roll-over effect can be separated from all the other spritesheets in the world.

Still, an exciting time when we can combine files based on what is the most logical grouping, rather than what is the most efficient. I look forward to the day when HTTP2 rules the world.

Re: Show HN: Initial release of H2O, and why HTTPD performance will matter in 2015

#47

Post by bkeroack »

nnx wrote: post #46
bkeroack wrote: post #44

If you're relying on HTTP for all your microservices, you're doing it wrong.

Why? What's wrong with this approach?

Latency, for one. "Microservice" means reaching out over the network to perform an action, not necessarily: make an HTTP connection, transfer JSON, receive JSON back and deserialize. Microservices can just as readily be performed via protocol buffers or Thrift over ZeroMQ, raw TCP/UDP, etc.

Re: Show HN: Initial release of H2O, and why HTTPD performance will matter in 2015

#48

Post by liveoneggs »

currysausage wrote: post #40
rkrzr wrote: post #2

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, thu…

> in fact the main reason I'm using nginx over Apache is that I don't want to deal with .htaccess any more. Wait, you don't use Apache because you don't like .htaccess files?

when wordpress is your hammer..

Re: Show HN: Initial release of H2O, and why HTTPD performance will matter in 2015

#49

Post by detaro »

stephth wrote: post #20

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 p…

> Edit: why the downvotes?

Because under seemingly every C project discussed here someone asks this question or claims that it is "stupid to do something like this in C" and always gets the same answers. Some users might have felt like you were trolling.

Post reply on HN