5 ms·

For all the hate given to PHP, I still can't understand why the cool-elite-rockstar-ninja-sexy-hot-hackers of python/ruby/java/go/haskell/clojure/S*t can't come

For all the hate given to PHP, I still can't understand why the cool-elite-rockstar-ninja-sexy-hot-hackers of python/ruby/java/go/haskell/clojure/S*t can't come up with half-as-dumb replacement for mod_php and compete with it on its own terms. Good variable names and documentation are infinitely more important than new shitty frameworks or do vs "{" vs "\t".

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.
dlitz 13y ago
Fun fact: mod_php can't safely coexist with anything else. A few years ago, I briefly ran a webserver that had both mod_python and mod_php installed at the same time. Everything seemed fine until I tried using md5 from Python and repeatedly got completely wrong values: >>> md5.md5("hello").hexdigest() '00000000000000005039985304054aac' >>> md5.md5("hello").hexdigest() '00000000000000009ebb1c1ea77b5505' As it turns out, both PHP and Python defined MD5Init, MD5Update, and MD5Final functions, with slightly different interfaces, and ld.so picked a winner to be shared by both of them. But I get your point about PHP's deployment story being one of its (arguably few) strong points.
- mfjordvald 13y ago
  Might one not say, then, that mod_python also cannot safely coexist with anything else? Seems neither decided to namespace that but you seem to decide to blame PHP?
  - davvolun 13y ago
    To be fair, blame mod_python all you want, seeing as it's deprecated, I don't think anyone cares. Meanwhile mod_php is...far from deprecated.
  - dlitz 13y ago
    The point is that the mod_* approach isn't sustainable.
kbenson 13y ago
It has nothing to do with variable names. People aren't rushing to make mod_* for other languages because it implies a lot of behavior (by nature of it being served through Apache) which isn't really the best idea for security. Having a structure that mixes the code files, templates (let's ignore mixing of logic and presentation), and static content all in the same publicly accessible location is just asking for security problems. You can lock down what's accessible or not based on file extensions, but that's through a config that's not part of the deployment (Apache conf) so it's not as easily controlled in your code, or if it is part of the deployment (htaccess), can be affected or overridden by directives nowhere near your code (Apache conf). It's fun when someone breaks the php loading directives in the Apache config and your code starts showing as plain text. You made sure not to hard-code ANY credentials in your PHP files that are publicly reachable, right? Your config isn't publicly reachable, is it? The closest you are going to get to something sane here is to approximate what the other frameworks are doing, which is to create a completely different site root, and a directory structure that completely separates your public content from your code, and point Apache at the public dir, not the code root. Unfortunately this does nothing to mitigate the problem of someone breaking any URL rewriting you need going on at the global Apache config, nor does it make it any easier to deal with crazy rewriting rules in Apache. Apache is great at serving content; Apache isn't the best choice anymore for serving applications.
- cadalac 13y ago
  >Apache is great at serving content; Apache isn't the best choice anymore for serving applications. What is?
  - kbenson 13y ago
    To clarify, it's not the best choice for serving applications where Apache works as anything but a proxy. For what's best, take your pick of any framework that entirely decouples the application directory structure from the routes and keeps the logic for it all completely internalized. All logic for how URI's are handled should be within the application configuration or code. Something written in the target language will probably provide far more benefits than whatever is lost through Apache. Whether Apache is in the path to your application is irrelevant, whether Apache does anything except note that a request should be handled by another application and hand the entire request off without change is not.

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.

dlitz 13y ago

Fun fact: mod_php can't safely coexist with anything else. A few years ago, I briefly ran a webserver that had both mod_python and mod_php installed at the same time. Everything seemed fine until I tried using md5 from Python and repeatedly got completely wrong values: >>> md5.md5("hello").hexdigest() '00000000000000005039985304054aac' >>> md5.md5("hello").hexdigest() '00000000000000009ebb1c1ea77b5505' As it turns out, both PHP and Python defined MD5Init, MD5Update, and MD5Final functions, with slightly different interfaces, and ld.so picked a winner to be shared by both of them. But I get your point about PHP's deployment story being one of its (arguably few) strong points.

mfjordvald 13y ago
Might one not say, then, that mod_python also cannot safely coexist with anything else? Seems neither decided to namespace that but you seem to decide to blame PHP?
- davvolun 13y ago
  To be fair, blame mod_python all you want, seeing as it's deprecated, I don't think anyone cares. Meanwhile mod_php is...far from deprecated.
- dlitz 13y ago
  The point is that the mod_* approach isn't sustainable.

kbenson 13y ago

It has nothing to do with variable names. People aren't rushing to make mod_* for other languages because it implies a lot of behavior (by nature of it being served through Apache) which isn't really the best idea for security. Having a structure that mixes the code files, templates (let's ignore mixing of logic and presentation), and static content all in the same publicly accessible location is just asking for security problems. You can lock down what's accessible or not based on file extensions, but that's through a config that's not part of the deployment (Apache conf) so it's not as easily controlled in your code, or if it is part of the deployment (htaccess), can be affected or overridden by directives nowhere near your code (Apache conf). It's fun when someone breaks the php loading directives in the Apache config and your code starts showing as plain text. You made sure not to hard-code ANY credentials in your PHP files that are publicly reachable, right? Your config isn't publicly reachable, is it? The closest you are going to get to something sane here is to approximate what the other frameworks are doing, which is to create a completely different site root, and a directory structure that completely separates your public content from your code, and point Apache at the public dir, not the code root. Unfortunately this does nothing to mitigate the problem of someone breaking any URL rewriting you need going on at the global Apache config, nor does it make it any easier to deal with crazy rewriting rules in Apache. Apache is great at serving content; Apache isn't the best choice anymore for serving applications.

cadalac 13y ago
>Apache is great at serving content; Apache isn't the best choice anymore for serving applications. What is?
- kbenson 13y ago
  To clarify, it's not the best choice for serving applications where Apache works as anything but a proxy. For what's best, take your pick of any framework that entirely decouples the application directory structure from the routes and keeps the logic for it all completely internalized. All logic for how URI's are handled should be within the application configuration or code. Something written in the target language will probably provide far more benefits than whatever is lost through Apache. Whether Apache is in the path to your application is irrelevant, whether Apache does anything except note that a request should be handled by another application and hand the entire request off without change is not.