4 ms·

Congrats on shipping! This project looks very interesting already and will hopefully pick up more contributors. Is there already support for configuration file

by rkrzr 12y ago

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.

Synless 12y ago
If you changed that to using the Hawaitha config format it would be perfect ;)
xorcist 12y ago
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.)
- lonnyk 12y ago
  > as evidenced by the (former, hopefully) widespread use of exploitable php calls Could someone elaborate on what this is referring to?
  - meowface 12y ago
    Read through https://nealpoole.com/blog/2011/04/setting-up-php-fastcgi-and-nginx-dont-trust-the-tutorials-check-your-configuration/ https://nealpoole.com/blog/2011/04/setting-up-php-fastcgi-an...
    - makomk 12y ago
      That's not really nginx's fault, its behaviour is quite sensible. The main problem is that PHP does some poorly-documented magic behind the scenes[1] that modifies the information nginx gives it in a way that causes security issues. The solution is not to do that; if you really need the path-splitting functionality that cgi.fix_pathinfo provides, it's better and safer to set fastcgi_split_path_info in the nginx configuration instead. [1] http://php.net/manual/en/ini.core.php#ini.cgi.fix-pathinfo http://php.net/manual/en/ini.core.php#ini.cgi.fix-pathinfo - the docs on cgi.fix_pathinfo don't mention that it affects which PHP file gets executed at all.
- meowface 12y ago
  >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.
  - xorcist 12y ago
    It's a well documented feature that has existed since always. The vulnerability arises because the obvious way to configure this handler in nginx is to write regexps. You could just as well have handed the user a loaded gun pointed at their foot.
- lumpypua 12y ago
  Like a lot of configurations formats the semantics of nginx's config files has pitfalls: http://wiki.nginx.org/IfIsEvil http://wiki.nginx.org/IfIsEvil Not a fan of nginx's config but I'm a huge fan of nginx.
kazuho 12y ago
Thank you for the comments. The configuration file format is YAML, and the directives can be seen by running `h2o --help` (the output of version 0.9.0 is: https://gist.github.com/kazuho/f15b79211ea76f1bf6e5 https://gist.github.com/kazuho/f15b79211ea76f1bf6e5). 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.
- rapind 12y ago
  Ooh I definitely prefer your YAML configs.
- rubyfan 12y ago
  @kazuho any examples of setting up filters or handlers via config?
currysausage 12y ago
> 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?
- liveoneggs 12y ago
  when wordpress is your hammer..
  - jacques_chester 12y ago
    ... everything looks like a thumb.
- rkrzr 12y ago
  Well, "main reason" may have been a bit of an exaggeration, but yes, I do think Apache's configuration syntax is truly awful. But of course I don't mind all the other awesome features you get by using nginx.

by rkrzr 12y ago

Synless 12y ago

If you changed that to using the Hawaitha config format it would be perfect ;)

xorcist 12y ago

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

lonnyk 12y ago
> as evidenced by the (former, hopefully) widespread use of exploitable php calls Could someone elaborate on what this is referring to?
- meowface 12y ago
  Read through https://nealpoole.com/blog/2011/04/setting-up-php-fastcgi-and-nginx-dont-trust-the-tutorials-check-your-configuration/ https://nealpoole.com/blog/2011/04/setting-up-php-fastcgi-an...
  - makomk 12y ago
    That's not really nginx's fault, its behaviour is quite sensible. The main problem is that PHP does some poorly-documented magic behind the scenes[1] that modifies the information nginx gives it in a way that causes security issues. The solution is not to do that; if you really need the path-splitting functionality that cgi.fix_pathinfo provides, it's better and safer to set fastcgi_split_path_info in the nginx configuration instead. [1] http://php.net/manual/en/ini.core.php#ini.cgi.fix-pathinfo http://php.net/manual/en/ini.core.php#ini.cgi.fix-pathinfo - the docs on cgi.fix_pathinfo don't mention that it affects which PHP file gets executed at all.
meowface 12y ago
>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.
- xorcist 12y ago
  It's a well documented feature that has existed since always. The vulnerability arises because the obvious way to configure this handler in nginx is to write regexps. You could just as well have handed the user a loaded gun pointed at their foot.
lumpypua 12y ago
Like a lot of configurations formats the semantics of nginx's config files has pitfalls: http://wiki.nginx.org/IfIsEvil http://wiki.nginx.org/IfIsEvil Not a fan of nginx's config but I'm a huge fan of nginx.

kazuho 12y ago

Thank you for the comments. The configuration file format is YAML, and the directives can be seen by running `h2o --help` (the output of version 0.9.0 is: https://gist.github.com/kazuho/f15b79211ea76f1bf6e5 https://gist.github.com/kazuho/f15b79211ea76f1bf6e5). 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.

rapind 12y ago
Ooh I definitely prefer your YAML configs.
rubyfan 12y ago
@kazuho any examples of setting up filters or handlers via config?

currysausage 12y ago

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

liveoneggs 12y ago
when wordpress is your hammer..
- jacques_chester 12y ago
  ... everything looks like a thumb.
rkrzr 12y ago
Well, "main reason" may have been a bit of an exaggeration, but yes, I do think Apache's configuration syntax is truly awful. But of course I don't mind all the other awesome features you get by using nginx.