[Improvement Request] htaccess-lite for nginx

[Pascal Nitsche]

  Am 08.12.2010 15:02, schrieb Grzegorz Nosek:
> It goes to hell by using PHP (or whatever heavy backend) anyway. Nginx 
> wins by serving static content extremely fast and by proxying with 
> very low overhead. If you use Apache for PHP mostly (I'm not sure 
> rewriting URLs to static content is at all popular), you're 
> effectively using Apache2+mod_php as a HTTP SAPI for PHP (with built 
> in htaccess support). It's more flexible than php_fcgi too (though 
> php-fpm offers some more options).

Apache is currently running as mpm-worker with php over fcgi anyway.

> You (usually) only do it once when deploying the app and given the 
> typical user you'll get a ticket anyway (teh htaccess is no worky!).

I myself am developing on a apache xampp configuration and testing with 
nginx and then documenting setup on nginx and apache. It's true most 
apps don't do this because nginx is not that wide spread with hosters at 
the moment but I think if nginx would support some things the users need 
(or think they need) and this is usable nginx would be used more and 
this would be documented more.
And with the tickets it's not that much a problem since I already 
informed the users that this will no longer work once I completly 
convert all vhosts to nginx (it's planned for the next weeks) and they 
should work on that themselves and only submit tickets like "please add 
rewrite rule xy" 'cause I will ignore questions like "Y is teh htaccess 
not worky?" - Who don't read my mails don't deserves an answer I think.

I'm now suggessting this feature to automate this a little.

> They'd need a way to reload nginx then (looking for htaccess-like 
> files upon every request would kill performance). How about deploying 
> an Nginx instance per user then?
nginx is reloaded every five minutes by the master cron of froxlor 
anyhow so this is not the problem. And everyone using it can just set up 
a cron reloading nginx periodically.

Furthermore I didn't mean to have configuration abilities in every file 
- just in one file (eg. .custom-config in the root dir or something) 
where they cut put their own additional configuration (it's better for 
maintrance too I think.
If this would be possible I think the great apps (Wordpress, Joomla etc) 
would have documentation on how to setup if using nginx really fast and 
the more nginx will be used by hostes the more documentation on that

Deploying more then one instance of nginx isn't really what I think is a 
good idea since this would be many in no time (at this point around 50 
or 60 )

Also it's working at the moment it's just a pain in the ass to have to 
set up this many things for users who just could do this themselves and 
then wouldn't need to wait hours until I can change the configuration 
and issue a reload (I am not available 24/7 and most people don't 
understand this and then complain "How long do you plan on making me 
wait?").

> You'd need a very thorough security audit of Nginx code because 
> (AFAIR) the setup is done in the master process while still 
> potentially running as root, so every vulnerability (in user-supplied 
> config files) at that stage equals immediate root. Nginx is written 
> far better than most software I've seen so this is less of a concern 
> but instead of full privilege separation, you're now this -><- close 
> to a compromise.
Therefore I would suggest to only allow directives which don't take you 
at risk like location, rewrite, expires... nothing actually changing 
directories outside the vhost or something... But I think you are right. 
It's kind of risky if it runs as root - which I don't think is a good 
method anyway it should run as an unprivileged user like ex. www-data 
(as on debian)At the moment the lack of some kind of possibility to add 
rewrites etc.
> Apache as a webserver sucks (compared to Nginx) but Apache as an 
> application server (mod_* container) isn't that bad.
Maybe true, but nginx is faster even with php-cgi. I tested this with a 
Zend application I wrote.
On apache the requests did take up to 5s (about 1.5s on average) and on 
nginx the average loading time was about 800ms (0.8s)
I tried with 50 requests each. (The times are a bit high both I think 
but the app was still in development and it's Zend Framework so it will 
go down when performance will be optimized anyway)

Also I do not like running dual-httpd setups really well because there 
are two configs to maintain then. And apache does not support proxying 
to a unix socket set (I tried with thin for redmine since I don't like 
passenger and I don't liike blocking 4 TCP ports for each thin 
application instance.)

So I think nginx is still better then apache even if apache isn't that 
bad a application server as you say.

> Best regards,
>  Grzegorz Nosek

Best regards,
Pascal Nitsche