Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

So the unusual thing about PHP (and, historically, mod_python, and CGI for that matter) is that it's normal to have the code actually under the web server's content directory tree. That is, if your content root is /var/www, then you put your code at /var/www/thing.php, so a deployment involves copying stuff into /var/www, and if the server is misconfigured, going to "https://example.com/thing.php" will actually show you the code.

For, say, Java or Ruby web apps, your code is more likely to live elsewhere (people love to fight over exactly _where_...), and run its own web server; nginx or apache or whatever will then proxy requests to that webserver. No matter how it's configured, you're never going to show the end-user the code, or extraneous files like .gitignore. Python's a bit of a corner-case (or at least it used to be last time I worked with Python webapps about a decade ago); it's customary to use WSGI or similar rather than a proper web server, but the effect is much the same.



That is very much not standard practice for PHP since about 10 years by now. Applications have a designated web root directory and an entry point that boots the application - as php is serverless by design - which is sometimes placed inside the web root by convention, but that is neither a requirement nor a security risk.

By now, stateful application servers are also powering modern php deployments: They also listen to a socket, and keep parts of the application in memory, next to an event loop.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: