Using the PHP built-in server in production

Question

I was recently curious about PHP 5.4's built-in webserver. On the surface it seems as though, while rather barebones, with enough work it could be possible to distribute PHP applications that traditionally depend on a separate web server, like WordPress, as standalone scripts that you could just run with php -S localhost:80 app.php (or, more likely, './wordpress.sh'). They might even ship with their own PHP interpreter that has all the features the application needs, which would obviate the need for targeting many different versions of the language.

It's re-inventing the wheel somewhat, but it would certainly increase portability and reduce complexity for the end user.

However, I saw the following on the documentation page:

This web server was designed to aid application development. It may also be useful for testing purposes or for application demonstrations that are run in controlled environments. It is not intended to be a full-featured web server. It should not be used on a public network.

This would obviously refer to issues like proper filesystem security and serving the correct HTTP headers, which can be worked through. However, is there more to it? Are there inherent security concerns and/or technical limitations with using PHP's built-in web server in a production environment that can't be worked around? If so, what are they?

Answer 1

It is not intended for production use and may not be able to gracefully handle crashes and memory leaks, raising stability concerns. More importantly PHP itself warns of this explicitly:

Warning This web server was designed to aid application development. It may also be useful for testing purposes or for application demonstrations that are run in controlled environments. It is not intended to be a full-featured web server. It should not be used on a public network.

http://php.net/manual/en/features.commandline.webserver.php

Answer 2

PHP's built in server only supports HTTP/1.0, which means clients have to make a new TCP/IP connection for every request. This is very slow.

Answer 3

I can think of plenty of operational issues why you wouldn't want to do this:

• Logging
• Rewrites
• Throttling
• Efficiency (not tested, but I'm guessing Nginx is a lot faster than PHP's built-in non-optimized server)
• Integration with anything else you have that extends Nginx, Apache, and IIS (things like New Relic)

However, there is a solution where you get most of the benefit of running PHP with its built-in web server while getting most of the benefit of running a web server out front. That is, you could use a server like Nginx as a reverse proxy to PHP's built-in web server. In this situation, HTTP becomes a replacement for FastCGI, analogous to common usages of the built-in HTTP server in Node.js applications.

Now, I can't speak to the specifics of the warning in the documentation as I am not one of the PHP authors. If it were me, I'd not run PHP alone for the reasons above, but I might consider running it behind a real web server like Nginx. For me though, setting up PHP with PHP-FPM and what not isn't that difficult, and I'll take that over guessing at the seaworthiness of a built-in server that is documented to be for testing only.

Answer 4

The problem with PHP's built-in web server is that it is single threaded!

That has performance and security implications. Performance implications obviously are that only one user can be served at a time (until one request finishes, another can not start).

Security implications are that it's pretty easy to DOS that server, using a simple open socket that sends tiny amounts of data (similar to Slow Loris).

It's useful for simple, one-page, non-interactive applications that have no risk of denial of service.