
PHP Built-in web server - aritraghosh007
http://php.net/manual/en/features.commandline.webserver.php
======
rll
Note that one of the main pushes for having this right in the core
distribution was to improve our test framework. We can't rely on and end-user
installed web server for "make test" since we have no control over the
configuration and the current approach of faking GET/POST/Cookie data for the
CGI version only goes so far. Having an actual server where we can test things
like opcode caching where the first and second request to the same resource
hit wildly different code paths is a big win. It is also helpful during
debugging. The less moving parts the better when you are sitting in gdb or
Valgrind trying to track down a problem.

For end users I think the most interesting feature is the ability to provide a
router script that can wrap whatever frontend controller your framework is
using. And some projects support it natively now. For example, in Symphony2
you download and untar it then just cd into the directory and start _php -S
localhost:1234_ and off you go.

But please, don't ever use this as a replacement for Apache/nginx as a user-
visible web server.

~~~
chocolatebunny
I don't understand the "make test" thing. If you're temporarily hosting pages
for testing then doesn't that mean you have to also get something to pull
those pages to validate them? If that's the case then why can't you just
output stdout and validate the pages that way, with just some simple mechanism
to pass post/cookie information as a parameter (much like how you would do it
with wget).

~~~
maratd
> I don't understand the "make test" thing. If you're temporarily hosting
> pages ...

That has nothing to do with user code or hosting pages. Most people install
PHP using their package manager (ie "yum install php"). Some people and those
that maintain those packages, need to compile PHP from source code (PHP is
written in C). The guys who develop PHP wrote thousands of tests that make
sure that the binary that is compiled works properly. Those are the tests
being referenced.

~~~
hythloday
Right, I think the poster you're replying to understands that. The question is
that, given there's a command-line interpreter (php-cli), built as part of a
normal build, which will execute PHP files and print the output, why do your
tests need to go over HTTP at all?

~~~
maratd
> why do your tests need to go over HTTP at all?

Just off the top of my head, how would you check file_get_contents which can
take a url as a parameter?

You can't just throw <http://www.google.com/> in there. You might be compiling
on a machine that's not on the net, firewalled, etc.

It becomes useful for functionality that normally relies on an external http
server to work.

The OP also mentions several more scenarios where it is useful and even
necessary.

~~~
hythloday
That's a slightly different scenario - you're exercising client protocol
functionality. (Incidentally, you don't need a webserver for that, you just
need a very stupid socket server that will return a file. Also,
file_get_contents looks like it can access ftp/ssh/gopher URLs so if you need
a webserver, you also need servers that speak those other protocols).

------
stevencorona
Man, this got so much flack from the PHP community that didn't see the power
in having a built-in webserver. For some reason, people center on that it's
supposed to replace Apache/nginx, which it's not.

Languages and frameworks aside, one of the nicest and most newbie friendly
parts of Rails is that it's bundled with a webserver, so you can start playing
around without having to setup any sort of dev environment.

Edit: I do agree that this should probably not be in the core php interpreter,
though. Ideally, it would be a PHP library with a CLI utility, but with PHP's
poor culture and adoption towards shared libraries ala composer/rubygems/npm,
I think this is the best alternative.

~~~
ceejayoz
Precisely. This will hopefully replace a lot of the "FTP it up to the server,
see if it works" workflow I've seen in the PHP world.

~~~
drbawb
To be honest: that was quite possibly the greatest part of learning PHP for
me!

PHP was the first language I learned; the fact that I could deploy it to
nearly _any_ shared host [of which there were a lot of freebies] allowed me to
rapidly program and debug; which I find was crucial to my initial learning.

Hindsight being 20/20: of course I agree with you, now.

But I'm still not convinced that _young me_ would've been able to use the
built in server. I certainly couldn't be bothered to setup Apache (et al) and
a working PHP interpreter.

Rails is a bit different, since you learn about the built in webserver when
going through their "hello, world" tutorial. If excellent tutorials surface
for PHP, then perhaps I can see the "FTP-to-test" pattern being obsoleted.

To me: PHP's greatest asset was that A) I didn't have to setup _my own_
development environment, and B) there were so many [free] development
environments already setup!

I'd learn to love setting up servers, but that came far later [in my
chronology anyways].

tl;dr: FTP and common PHP setups actually removed a large barrier to entry for
a young programmer. I think the "FTP-to-test" anti-pattern was probably one of
the more useful ones in my toolkit when it came to my initial learning.

~~~
geofft
Wait, running the built-in server is one command (and no configuration), and
it's quite reasonably claimed that Rails' equivalent built-in command is
helping the adoption of Rails by people who are now in the position where you
previously were.

It seems to me like it should be at least as easy to fire up the built-in web
server as to learn FTP and sign up for some random shared hosting account,
right? That is to say, isn't this even a lower barrier to entry than the FTP
approach?

------
cmelbye
This is seriously so fantastic. In my case, the biggest barrier to me
contributing to projects that use PHP is the pain of setting up Apache/nginx,
making sure permissions are right on the directory for apache to serve it,
setting up virtual hosts, etc.

This built-in web server has singlehandedly influenced me to actually look at
using PHP for projects.

~~~
clone1018
sudo apt-get install nginx php5-common php5-fpm is all you have to do :\

~~~
cmelbye
Haha, I knew someone would tell me "but it's easy to set up nginx and PHP!!!"

I really don't agree. "php -S localhost:8888" is much, much easier. Let's
leave it at that.

------
Joeboy
I used this last week to reverse engineer some PHP code supplied by a third
party. Was very pleased how easy and non-invasive it was - just built PHP from
source and ran the executable direct from the build tree. Swore at PHP much
less than I would otherwise have done.

------
mariuz
You don't need a full server like apache or nginx to start developing in you
home all you need is php

I like it is like in the rails/django world

~~~
pablasso
"I like it is like in the ruby/python world"

~~~
menacingly
I think in this instance, "ruby" is more accurate. they didn't say "it is an
exclusive property of rails", just that Rails has it, which is true. It's more
true than saying Ruby has it.

edit: removed completely presumptuous gender pronouns

------
latimer
I can't remember where I read it, but I believe Rasmus stated that the
original purpose of this was to simplify the PHP test cases. Since they
couldn't assume that a user had a given web server installed, they had to use
weird hacks to make PHP think it was running behind a web server and even then
it couldn't test everything.

~~~
slig
His reply on this thread <http://news.ycombinator.com/item?id=4502041>

~~~
latimer
Oops didn't see that he had already posted that.

------
programminggeek
This is maybe my favorite new feature in PHP. In ruby I'm so used to just
running shotgun locally and not having to install MAMP, XAMP, WAMP or any of
those other things I used to have to deal with just to get a little web server
working to develop against. Good job PHP.

------
dhotson
I had a go at a Rack/WSGI style PHP web server a while ago:

<http://getkelpie.com/>

.. it's using the mongrel http parser wrapped in a PHP extension, so it's
pretty fast and reliable: <https://github.com/dhotson/httpparser-php>

I tried it at work and got pretty significant performance increase since it
only has to initialize the framework at server startup instead of every
request. We went from a baseline of 70ms to about 2ms per request.

------
adunar
For those still using PHP 5.3, you can use
<https://github.com/youngj/httpserver> (disclaimer: I wrote it) -- it's a
standalone development HTTP server written in PHP that only depends on the
php-cgi binary.

Even with PHP 5.4, I find it more useful for development than the built-in
cli-server, since it gives me more flexibility to simulate the various
directives in my nginx configuration files (e.g. gzip_static).

------
krallja
Sometimes I feel like The Twelve-Factor App is basically a response to all the
horrible things PHP makes you do. Now there's one less reason to hate PHP.
<http://www.12factor.net/port-binding>

~~~
ceejayoz
This isn't intended for production use.

PHP-FPM is, though, and it's been around for quite some time.

------
Axsuul
Wow, this is a big deal. Even though I don't work with PHP all that much
anymore, I really wish I had something like this when I did.

------
jakeburtn
Well that could come in pretty handy.

------
acabal
I can see how this can come in handy, but setting up a LAMP server on
localhost is so easy nowadays that I can't help but think this is a little
redundant. Sure you get a full-blown Apache install but honestly, calling that
bloat is semantics on anything but the worst of developer machines. I wish
they had spent the manpower working on core language features instead.

~~~
nateabele
Core language features? Oh, you mean like all these guys?
[http://nikic.github.com/2012/07/10/What-PHP-5-5-might-
look-l...](http://nikic.github.com/2012/07/10/What-PHP-5-5-might-look-
like.html)

~~~
acabal
I'm not saying things aren't progressing, all I'm saying is that on any
project there's a limited amount of manpower, and how you allocate that
manpower is important. Personally I think there are more pressing things to
allocate manpower to in PHP than a built-in web server, when Apache is already
so simple to configure for serving PHP.

Furthermore this kind of web server would only be useful for the most basic of
projects. As soon as a person dips their toes into anything remotely complex,
they're going to need their development server to mirror the production server
as closely as possible, especially with things like php.ini and rewrites. So
why not just set it up like that to begin with?

~~~
robryan
It is an open source project, I am guessing that one or more contributors
decided they wanted the built in be web server.

There is nothing stopping others getting involved if there were other things
they want to see in future PHP versions.

