By Craig Buckler

PHP 5.4’s New Built-in Web Server

By Craig Buckler

One of the more interesting facilities provided in PHP 5.4 is a built-in web server. It runs from the command line on Windows, Mac or Linux. You just need to ‘cd’ to the folder where your application resides then execute:

php -S localhost:8000

This will start a console-based web server. The document root is located in the current folder:

PHP 5.4.0 Development Server started at Mon Dec 19 11:56:05 2011
Listening on localhost:8000
Document root is /home/owner/myapp
Press Ctrl-C to quit

You can then open http://localhost:8000/ in your browser. If you don’t explicitly include a filename, the server will return either index.php or index.html in the root folder. All file requests are logged to the console window.

It’s also possible to specify a PHP “router” file on the command line, e.g.

php -S localhost:8000 -t ./home/owner/myapp routing.php

The server analyzes the output of routing.php:

  • If the script returns false, the requested resource (or 404) is returned as-is.
  • If the script returns anything else, that output is returned to the browser.

For example, the following router script will return image files but all other requests will display “Welcome to the PHP Server!”:

if (preg_match('/.(?:png|jpg|jpeg|gif)$/', $_SERVER['REQUEST_URI']))
	return false; // serve the requested image
else {
	echo "<p>Welcome to the PHP Server!</p>";

PHP 5.4’s web server is intended for development purposes and I suspect it will be adopted by text editors, IDEs and possibly browser plug-ins as an easy way to test PHP code.

There’s no reason why you couldn’t use it on small internal server — and some people will try — but there are certainly more appropriate solutions. However, we could see a few interesting uses such as web application demonstrations which can run from a CD.

PHP 5.4 RC1 was released recently. I doubt you’ll need to wait long for the final version.

  • This looks like a nice new way to test your PHP code. But, will it be useful enough for a developer to debug his code, when most of the PHP scripts on the web run on an Apache server?

    • In general, I’d recommend writing PHP code to be as server-agnostic as possible. You can normally write code so it works on Apache, IIS or any other platform.

      I suspect the biggest issue will be mod-rewrite: configuring the system to use human and SEO-friendly URLs. Although the router script could provide an alternative.

  • Selorm Nelson

    great news!! but is that the only new feature added to the version 5.3??

    • Robbo

      LOL no… there is a lot added…

    • No – there are other features, but it’s not a major revision like 5.3 was.

  • Leonard Challis

    Interesting… I’ve never tried but I presume you can put the PHP distributable on a thumb drive and use it as a portable development environment. Might be worth playing with.

  • About time, taking the setup of apache out of the mix is great news.

    I’ve been using phpup to generate minimal apache configs for a while now, speeds up testing new code considerably.

  • Am I correct to assume that the installation of this automatically creates a respective class path (environment) variable? Seems simple enough to use judging from your write-up, but I think I’m sticking with my WAMP sandbox for the time being. I just don’t think it can be beat for development at the moment–though I’m sure there’s some sandbox apps that could probably do just as good… Just haven’t used them yet. Never had to! :.)

    • It’s probably best to wait until the gold version to say for sure, but the PHP server will almost certainly offer a range of standard environment variables. How close they are to Apache equivalents is another matter.

  • Stash

    I am thinking this may be a dirt simple way to implement a Model/Data server. A light weight JSON response server you can access from anywhere. Cross Platform, Small Footprint, and Feature Rich in terms of data manipulation. Seems like a nice addition.

  • @FuzzFree: Using PATH_INFO (which is what you’re talking about) does work nicely, but it can have potential performance issues. Imagine you had a URL like /pages/aboutus.php/hello/world/foo. To determine where to send the request, it needs to do the following steps:
    1. Check if /pages/aboutus.php/hello/world/foo is a file – No
    2. Check if /pages/aboutus.php/hello/world is a file (with path_info of foo) – No
    3. Check if /pages/aboutus.php/hello is a file (with path_info of world/foo) – No
    4. Check if /pages/aboutus.php is a file (with path_info of hello/world/foo) – Yes

    It’s not smart enough to know that aboutus.php is a file, so needs to traverse backwards along the URL until it finds the file you’re referencing. It can’t just assume that anything with a dot in it is a file, as you could have a directory called “aboutus.php” (and /pages/aboutus.php/hello/world/foo could be an actual HTML file). I’m not sure how much of this processing is cached.

    You avoid these performance issues but get similar functionality by just using a single rewrite rule (rewrite all request for non-existent files to something like index.php?route=$1), and disabling path_info. You’d then handle $_GET[‘route’] in your router, similar to what you’d do with $_SERVER[‘PATH_INFO’] or $_SERVER[‘REQUEST_URI’]

    • Yes I agree. My point was to use REQUEST_URI (forgot to expand on the asterisk – depending on server/os you get the desired value) JUST to avoid the rules for webservers (so there will be zero configuration for iis, apache etc..).

      Now if there are multiple entry script points (aboutus.php, faq.php etc.) is another discussion. The above example would be /index.php/pages/aboutus (for example just like OJS or Joomla with SEF but without mod_rewrite etc.).

      As for /pages/aboutus.php/hello/world/foo – the entry script is /pages/aboutus.php (webserver handles this). This script knows what to do with hello/world/foo :)

  • lol……

Get the latest in Front-end, once a week, for free.