On Mon, Dec 29, 2014 at 10:41:26PM +0000, Stuart Henderson wrote: > > b) Migrate to nginx > > This seems to be the least interesting option - not only do I have to > > migrate now, but once more in the future, as nginx is also on the way > > out (so, the same "developer attention" caveat applies as with > > apache) > > This might be a reasonable choice, especially if the CMS you're looking > at already documents how to use it with nginx. >
We already got some of the most common CMS / web things working. But I'm interested in examples from users who created such configurations with httpd (and please make sure to mention httpd in the subject to let me find them in my inbox). > > c) Migrate to httpd > > From what I've gathered so far from this list, this would basically > > require me to switch to -current, as the 5.6 version is too fresh and > > too many changes have happened since - or am I being pessimistic > > here? I've never run -current before, hence, I'm a bit hesitant... > > Personally I don't think httpd is quite ready for use with a typical > PHP-based CMS yet (including -current). Two big issues for this type > of use: "clean urls" functionality in most CMS needs rewrite support > which httpd doesn't have. httpd's fastcgi support passes every url > matching a location block to the handler meaning there's no mitigation > for the issue described in > http://wiki.nginx.org/Pitfalls#Passing_Uncontrolled_Requests_to_PHP > (which also affects naive nginx configurations). > And I personally disagree with the conclusion that httpd is not ready. It is not finished but it is ready for many common things. - People are using it with different "CMS", including Wordpress, CVSWeb, different Wikis, etc. I even tested it with node-fastcgi (I know, it's weird, but I had to satisfy my inner web hipster). I'm looking forward to hear about more examples (hint: send me your testimonials). - Some features are missing, and will be implemented, but there are ways to deal with them: 1. redirects / return 301 etc.: This can be done without regex by using a few built-in variables. Current workaround is to either do it in the fastcgi backend or with, ahem, html refresh. btw., nginx' "return 444;" is such an ugly workaround... 2. basic auth: We don't have a satisfying implementation for authentication yet. But it is needed and will be done. 3. deny: We cannot deny access to specific locations but the current workaround is to set a non-accessible root: location "*/.*" { # mkdir -m 0 /var/www/forbidden root "/forbidden" } 4. Server aliases and a few restrictions of the grammar: Individual server blocks can currently only have one name and listen statement. This will be fixed in the parser later. To avoid too much repeating configuration, I currently use includes: server "www.example.com" { listen on $ip4_addr port 80 include "/etc/httpd/example.com.inc" } server "www.example.com" { listen on $ip6_addr port 80 include "/etc/httpd/example.com.inc" } server "www.example.com" { listen on $ip4_addr tls port 443 include "/etc/httpd/example.com.ssl" include "/etc/httpd/example.com.inc" } server "www.example.com" { listen on $ip6_addr tls port 443 include "/etc/httpd/example.com.ssl" include "/etc/httpd/example.com.inc" } 5. Some minor things, eg. charsets (for auto index), fixes, ... 6. The web server needs some more FAQ-style documentation in addition to our excellent man pages and examples. Examples for each CMS would go beyond the scope of them, and probably don't fit into the OpenBSD FAQ. So I'm thinking about putting something on http://bsd.plumbing/. - Like nginx describes, there are also various ways to safely handle #Passing_Uncontrolled_Requests_to_PHP in httpd: 1. It's a non-issue for OpenBSD because php-fpm rejects execution of non-php files by default. See php-fpm.conf: ; Limits the extensions of the main script FPM will allow to parse. This can ; prevent configuration mistakes on the web server side. You should only limit ; FPM to .php extensions to prevent malicious users to use other extensions to ; exectute php code. ; Note: set an empty value to allow all extensions. ; Default Value: .php ;security.limit_extensions = .php .php3 .php4 .php5 2. You can write locations as a ruleset in first-matching order, eg. location "*/.*" { root "/forbidden" } location "/cms/*.jpg" { no fastcgi } location "/cms/uploads/*" { no fastcgi } location "/cms/*" { fastcgi socket "run/php-fpm.sock" } 3. Don't use PATH_INFO and only match PHP files (fnmatch has an implicit $). location "/cms/*.php" { fastcgi socket "run/php-fpm.sock" } - I think that excessive use of regex and rewrites are workarounds for poorly written backends (aka CMS) and most of the time neither required or recommended. Even nginx' Pitfalls document clearly suggest to prefer the simple ways over complex regex and if blocks. They say "If is Evil", so why would I add it in the first place? Most rewrites can be replaced with return statements and some pre-defined variables - so we need return statements, not rewrites. - I still don't want regex in httpd. If you insist on using them, go ahead and install nginx from ports. Totally fine with me. But you don't have to. We don't have to repeat all things all over again. - You can also combine httpd with relayd to get some additional functionality. There is no need to put all the stuff (load balancing, complex relaying, proxy, ...) into one daemon. nginx is trying to do too much in one single tool. [...] Reyk
