6 ms·

Because mod_php is one of the main things that said hackers don't like about PHP. 1 file to 1 url does not scale to even small blogs, and using mod_rewrite to

by vec 13y ago

Because mod_php is one of the main things that said hackers don't like about PHP. 1 file to 1 url does not scale to even small blogs, and using mod_rewrite to handle routing is both more complicated and less powerful than port forwarding to an app server and letting it handle urls in application code. I always hear people say this, but I've used both a fair bit and `rails s` plus port forwarding is an order of magnitude easier than fighting with apache's vhost config.

frenchy 13y ago
> 1 file to 1 url does not scale to even small blogs, I suspect you are aware of this, but using URL parameters it is quite easy to make multiple urls map to the same file (i.e. `/foo/?abc=123` and `/foo/?abc=234`).
- vec 13y ago
  Of course you can, but most of the time you don't want /blog/index.php?slug=title-of-the-article, you want /blog/title-of-the-article. To do this in a CGI-style app (i.e. mod_whatever) you've got to mangle the URL in the webserver layer. This moves application logic out of the application and into a config file for some other program, so it would be bad even if Apache's rewrite syntax wasn't incomprehensible black magic. It cuts both ways, too. CGI-style routing gives a URL to everything, whether you want to or not. Unless you explicitly disable it, visiting /blog/config/database_credentials.ini (or whatever) will happily serve that file to the client. Plus it allows any user to execute the code in any file in your system out of context. Admittedly this will probably either error out or do nothing, but can you guarantee that for every single code file in your whole tree?
  - Kiro 13y ago
    The only rewrite rule you need is one to direct all requests to index.php. Then you just parse the URL in PHP to achieve /blog/title-of-the-article. What is the problem with this approach?
  - Mahn 13y ago
    Technically speaking you would need one single rule in your web server configuration that rewrites all urls to a single router.php file (for instance), and code there your own logic to handle urls in PHP. This is not very different from other server languages except for the fact that you are in control of the routing logic AND you can delegate it to a framework if you choose to do so. I've been using this technique (single url rewrite rule, send everything to index.php, handle routing there) for some time and it's worked quite well for me.
iso8859-1 13y ago
I think you are simplifying a bit. AFAIK, the slow performance of mod_php is a result of the massive memory foot-print that each Apache worker process will have. The operating system can cache hundreds of 10 KB PHP files without problem, it doesn't make a difference how many files you have when they are all small and cached. So, in conclusion, I propose that PHP performance is OK if you use something like php-fpm.
icelancer 13y ago
>1 file to 1 url does not scale to even small blogs Huh? You can use a lightweight framework like CodeIgniter to immediately remove this problem.
- vec 13y ago
  Yes, any half-decent PHP framework will have some solution for this. CodeIgniter, in particular, gets around it with a combination of .htaccess files in every root directory, index.html pages in every subdirectory, and a boilerplate `defined('BASEPATH') OR exit('No direct script access allowed');` snippet at the top of every file. As long as the developer continues this convention through all their additions, this works quite well and is very secure and stable. It's also completely unnecessary. And it breaks if you want to host under nginx or lighttpd or anything that's not apache. The point is that this is a problem web frameworks don't have to have in the first place. It is relatively easy to fix, if you know how, but it creates boilerplate code and adds potential for security holes for literally no benefit. The ability to heal a self-inflicted wound is a poor substitute substitute for not being injured in the first place.
  - tmzt 13y ago
    The downloadable distribution of CodeIgniter and many other PHP frameworks have those file and boilerplate to protect badly configured Apache setups where the user just unzips the downloaded distribution into public_html. If you have .php files handled by PHP, or you have the mod rewrite htaccess rules enabled, the PHP files won't be exposed to the user. None of these are necessary if you have properly configured your web server.

by vec 13y ago

frenchy 13y ago

> 1 file to 1 url does not scale to even small blogs, I suspect you are aware of this, but using URL parameters it is quite easy to make multiple urls map to the same file (i.e. `/foo/?abc=123` and `/foo/?abc=234`).

vec 13y ago
Of course you can, but most of the time you don't want /blog/index.php?slug=title-of-the-article, you want /blog/title-of-the-article. To do this in a CGI-style app (i.e. mod_whatever) you've got to mangle the URL in the webserver layer. This moves application logic out of the application and into a config file for some other program, so it would be bad even if Apache's rewrite syntax wasn't incomprehensible black magic. It cuts both ways, too. CGI-style routing gives a URL to everything, whether you want to or not. Unless you explicitly disable it, visiting /blog/config/database_credentials.ini (or whatever) will happily serve that file to the client. Plus it allows any user to execute the code in any file in your system out of context. Admittedly this will probably either error out or do nothing, but can you guarantee that for every single code file in your whole tree?
- Kiro 13y ago
  The only rewrite rule you need is one to direct all requests to index.php. Then you just parse the URL in PHP to achieve /blog/title-of-the-article. What is the problem with this approach?
- Mahn 13y ago
  Technically speaking you would need one single rule in your web server configuration that rewrites all urls to a single router.php file (for instance), and code there your own logic to handle urls in PHP. This is not very different from other server languages except for the fact that you are in control of the routing logic AND you can delegate it to a framework if you choose to do so. I've been using this technique (single url rewrite rule, send everything to index.php, handle routing there) for some time and it's worked quite well for me.

iso8859-1 13y ago

I think you are simplifying a bit. AFAIK, the slow performance of mod_php is a result of the massive memory foot-print that each Apache worker process will have. The operating system can cache hundreds of 10 KB PHP files without problem, it doesn't make a difference how many files you have when they are all small and cached. So, in conclusion, I propose that PHP performance is OK if you use something like php-fpm.

icelancer 13y ago

>1 file to 1 url does not scale to even small blogs Huh? You can use a lightweight framework like CodeIgniter to immediately remove this problem.

vec 13y ago
Yes, any half-decent PHP framework will have some solution for this. CodeIgniter, in particular, gets around it with a combination of .htaccess files in every root directory, index.html pages in every subdirectory, and a boilerplate `defined('BASEPATH') OR exit('No direct script access allowed');` snippet at the top of every file. As long as the developer continues this convention through all their additions, this works quite well and is very secure and stable. It's also completely unnecessary. And it breaks if you want to host under nginx or lighttpd or anything that's not apache. The point is that this is a problem web frameworks don't have to have in the first place. It is relatively easy to fix, if you know how, but it creates boilerplate code and adds potential for security holes for literally no benefit. The ability to heal a self-inflicted wound is a poor substitute substitute for not being injured in the first place.
- tmzt 13y ago
  The downloadable distribution of CodeIgniter and many other PHP frameworks have those file and boilerplate to protect badly configured Apache setups where the user just unzips the downloaded distribution into public_html. If you have .php files handled by PHP, or you have the mod rewrite htaccess rules enabled, the PHP files won't be exposed to the user. None of these are necessary if you have properly configured your web server.