
A Built-in Web Server For PHP - taylorbuley
http://wiki.php.net/rfc/builtinwebserver
======
nir
What's the deal with the negative comments? You basically get this feature as
a gift. If you don't use it, you won't be affected by it in any way. If you
do, you get to enjoy the author's labor for free. Where's the problem here?

Any idiot can write a snarky comment about PHP. Very few get to write code
that has anywhere near the impact it had.

~~~
illumin8
The problem is that this encourages lazy development. Many developers love the
ability of tools like Tomcat that allow you to run your web app inside of the
application server itself, rather than having to configure a pesky Apache
server.

The problem this creates is that once a developer has it running on their own
machine inside Tomcat (or now this PHP built-in webserver) the app is probably
coded in such a way that it will ONLY run inside this server, and will never
scale. What's more, they often turn it into a production application with real
customers depending on it, and blame you if you can't make it scale to handle
hundreds or thousands of users.

This is the problem with using "built in" webservers. It encourages developer
laziness, and encourages people to kick bad code over the fence to the
operations team who has to make it reliable and run in production. Never mind
that a built in PHP webserver will never scale to meet the needs of more than
a few users.

~~~
hartror
Sounds more like a procedural issue being created by poor programmers and bad
management. Not testing it on a production-like environment is a capital
offense whether you are using a development server or apache/lighttpd/nginx.

~~~
wisty
I think it's better if the devs run something close to the production
environment.

The problem is, web developers already have a lot on their plate.

LAMP. The operating system, the web server, the database, and the scripting
language. Plus HTML, Javascript, and CSS. And all the frameworks that
"simplify" making these work together nicely. Then they have to figure out how
to deploy on the test and prod servers. Oh, and they better back _everything_
up. And some redundancy would be good.

That's on top of the existing requirements:

\- VCS \- Bug tracking \- Documentation \- Project management (Scrum? PMI?
Flying-by-the-seat-of-their-pants?) \- UX / UI design \- Unit tests

Not to mention having some domain knowledge. The above is fine for a to-do
list, but they might also need to know how to solve "real" problems, not just
do IT.

~~~
roel_v
"I think it's better if the devs run something close to the production
environment."

I used to think so too, but I changed my mind a few years ago. Have diversity
in the environment in the phases leading up to staging/testing leads to many
problems being uncovered early - hardcoded paths, platform assumptions,
potential performance issues that only show under some circumstances, ...

I think it improves the code if various devs use different installation paths,
DB's, development tools and even OS's. I've seen many deployment issues that
would have trivially been detected if devs had different environments.

------
jarin
Hopefully this will end the long-standing practice of novice PHP developers
writing code and pushing it to production to test it (or worse, editing code
on the production server).

Yes, I know you can set up Apache and mod_php or whatever, but starting a
server from the command line is just awesomer. You'll see, guys!

~~~
Ixiaus
This is probably the biggest potential win for this feature as long as said
developers understand the difference between the inbuilt webserver and the
production server (the difference between python paste and apache/mod_wsgi).

------
indeyets
This is a great addition to php's toolset.

And for those, who want greater flexibility,
<https://github.com/indeyets/appserver-in-php> is a Ruby-Rack/Python-WSGI
style solution which gives you possibility to initialise objects, open db-
connections, pre-warm caches, etc. before serving requests. Provides HTTP,
SCGI and Mongrel2 interfaces

~~~
bergie
Here is how we use the PHP AppServer in Midgard Create. Very easy setup:

[http://bergie.iki.fi/blog/introducing_the_midgard_create_use...](http://bergie.iki.fi/blog/introducing_the_midgard_create_user_interface/#5ef787a743aaa025fb1edb5f7086eab1)

------
jsdalton
Seems like this would be useful for development. It'd be great to be able to
print to the console for debugging purposes etc. while working on something.

~~~
there
i use error_log() for that and just tail apache's error log.

for dumping arrays and things, i use an error_log_r() which just does print_r
to the error log:

    
    
         function error_log_r($obj) {
             ob_start();
             print_r($obj);
             $lines = explode("\n", ob_get_clean());
             
             foreach ($lines as $line)
                 error_log($line);
         }

~~~
shaunxcode
Hey, rather than using ob_start and ob_get_clean you can do:

    
    
      $lines = explode("\n", print_r($obj,1));
    

Or better yet if we're playing golf:

    
    
      array_map('error_log', explode("\n", print_r($obj, 1)));

~~~
there
ah, i must have written that a very long time ago when the return parameter to
print_r() wasn't available.

thanks, i've updated my local implementation.

------
Supermighty
The best argument for PHP having it's own web server is to allow novice
developers an easy way to code and test their sites. I'll go out on a limb and
say I don't think the lack of a built in web server has hurt PHP's adoption in
the past.

And a built in web server would only be good for the novice tinkerer. I don't
see entrenched PHP shops switching, nor new applications being written
specifically for the build in server when Apache w/mods, nginx or LigHTTPD
offer better solutions (mature solutions) that are available now.

------
soulclap
I guess no one really needs this _bad_ but if someone's up to build it, why
not?

If it's kept as simple as the RFC suggests, it should be stable real soon and
there are definitely scenarios where I'd choose this over launching Apache or
even installing it, depending on the task and environment.

~~~
jerf
Give it some time to burn in first. Always give any new webserver time to burn
in first. I'm not sure that anyone has yet successfully produced a web server
that does not ship with the trivial directory traversal vulnerability on day
one, for instance.

I don't say this because it's PHP particularly either. Nobody seems to be able
to avoid really trivial and massive vulnerabilities in new web servers. I've
lost track of the number of times I've seen it. I'd link to a search of
osvdb.org for "directory traversal web server" but it seems to be down.

~~~
jamesgeck0
One thing the Symfony2 framework does that I sort of appreciate is limiting
access to the page to calls from localhost only by default. It seems like that
might mitigate some of the (no doubt gaping) security issues.

------
chrisallnutt
I feel this is trying to solve a problem where there isn't one. You can easily
install MAMP or XAMP and have access to a full stack if your developing on
your local machine. There are so many other higher priority items for PHP to
address.

~~~
tlrobinson
As a PHP newbie many years ago jarin's comment resonated with me:

 _"Hopefully this will end the long-standing practice of novice PHP developers
writing code and pushing it to production to test it (or worse, editing code
on the production server)."_

I was guilty of this because I just wanted to start writing code, not shave
yaks for an hour to get Apache and everything else installed.

Rails definitely got this right, I doubt it would be nearly as popular if it
weren't so freakin easy to get started on the tutorials. Not that PHP has a
popularity problem.

~~~
zidium
I guess you were just lazy.

There is practically never a valid excuse for uploading testing code to
production, unless the site is down __and __you already have everything under
revision control.

~~~
tlrobinson
Is being 14 years old and not knowing better a valid excuse?

I think it's good to encourage best practices even if everyone _should_ know
these things, especially for the newbies.

------
dhotson
I've already done something like this. I've implemented a Rack style web
server in PHP: <http://github.com/dhotson/kelpie>

I also wrote an extension for the mongrel HTTP parser, but you could probably
get away with a half-assed pure PHP HTTP parser.

<http://github.com/dhotson/httpparser-php>

It sounds crazy but it actually works pretty well. :-)

------
julianz
I like this idea. It would be handy on dev machines, and I would use it.

------
seldo
I really hate this idea. Coupling the server to the language seems like a
weakness in both django and rails to me, since it means deployment becomes
more of a scary hurdle, with possible changes in environment between your dev
server and production.

One of the strengths of PHP has always been for me that your development and
production environments are pretty much the same, and deployment is just a
matter of finding a way to copy the files over (and you can be as simple or
clever about that part as you like).

Teaching a newbie how to run the PHP server is not that much less complicated
than getting a default apache install running (especially with all the LAMP
and WAMP installers out there to do it for you), and then you'd have to teach
them about apache anyway before they pushed to prod.

~~~
andrewvc
I think that advice flies in the face of best practices.

1\. Your dev box isn't supposed to be very similar to production, this is why
you have staging servers. My dev boxes have weird tooling and debug tools.
They also run all services on a single box rather than distributed. Don't
pretend dev is at all like prod, this assumption will disappoint you.

2\. App servers, which generally speak HTTP and use a standard interface (in
ruby Rack, in Python WSGI) and speak HTTP to a load balancer (probably nginx).
Are simple and just work. They're less pain than setting up apache. `cd
myproject && rails server` is nice.

3\. There are about 10 billion things you can get wrong with setting up a
production server. If you can't figure out how to proxy requests to an app
server you have no business setting up a server in the first place. You've
probably already lost.

~~~
seldo
1\. My dev system is a series of VMs that mirror that same box deployments we
have in production, the only difference being that systems we duplicate for
redundancy in production are singular in dev. I've found that this prevents
accidental dependencies between libraries and processes that would otherwise
complicate deployments and scaling.

2\. For me, "apt-get install apache" once is much simpler and cleaner than
running a dev server every single time, but I have been doing it this way for
more than a decade, so perhaps you are right and I am just set in my ways.

3\. If you can't set up a production environment you can't set up a production
environment, and it doesn't matter which architecture is involved.

------
josephmoniz
NodePHP anyone? heh, afraid that would be a little more then just a SAPI
implementation though, we'd have to throw out a good chunk of the standard
library and very few if any extensions were coded for asynchronous execution.

An interesting thought though.

------
sberder
I don't really get it as the RFC clearly compares two different things. Web
servers included in _frameworks_ to ease the development (django/ror and
others like web.py) and a web server included in a cli interpreter which is
more or less the engine itself. For me there is a huge difference and mind gap
I'm not ready to do. I genuinely think that php is a convenient language for a
lot of things but implementing a simple class (like SimpleHTTPServer) looks
more natural to me than adding a server directly inside the cli.

------
cagenut
As much as I'm not so sure about the overall idea, it had never occurred to me
to look at cli php from this angle before. Rather than homegrow the
listener/invoker there I wonder how hard it would be to do this with xinetd.

Then there's the apc cache question, there would have to be some way of
persisting/sharing it.

Full blown goofy, but a little fun to ponder.

------
bluesnowmonkey
This is nice for a PHP cloud PaaS. Imagine the instructions for testing an app
locally before deploying it to the cloud. Instead of trying to coach the user
on setting up Apache (or whatever) in a way that mirrors your platform, you
just point them to "php -S".

------
Purefan
I would agree if the webserver was a functional replacement for apache in a
production machine. What I mean is that, if the built in server is more
efficient than apache and it can be used with performance gain (lets skip the
middle man)

------
TamDenholm
I know its kinda useless for anything other than "just because i can" but
anyone can code their own webserver in for PHP using PHP. Just saying. Might
be useful for development on your own machine or something.

------
hdragomir
I applaud this!

Django has this built in, Rails too. PHP went a step further and put this in
the core language and that makes sense because PHP in itself is meant for the
web, and is not a framework over some other language.

~~~
BerislavLopac
Actually, it is. PHP is a Web framework for C, except it uses its own syntax.
Or to be more precise, PHP is a templating engine for C, only it got out of
control.

------
bergie
We've been using a web/application server written in PHP for quite a while
now: <https://github.com/indeyets/appserver-in-php>

------
snissn
If they mean for it to only be used for development and not production, it
would be funny if they hard coded a specific set of 'normal' ports that it
would not work on!

------
litek
Couldn't one simply write a php script opening up a socket and routing the
request as fit? Is there a need for this in the core?

~~~
jonursenbach
It's unnecessary to have to write that every time you want this feature
though. Would be nice, and certainty more efficient, for it to be in the core.

~~~
litek
I'm just thinking this would be better suited for a quite simple php
script/framework you could download, since it's not in any way meant for
deployment.

~~~
indeyets
see my comment here: <http://news.ycombinator.com/item?id=2283301>

------
jacques_chester
Ouroboros has bitten its tail.

------
psaintla
no

------
acabal
Oh god... as if configuring Apache for a non-trivial site wasn't complicated
enough, now we'll have the full genius of those responsible for PHP's function
naming conventions writing their own web server? Is this _really_ necessary?
Why not spend the time making PHP's namespace support not suck, or working on
the SPL?

~~~
ary
Curious as to why you think PHP's namespace feature (I'll assume you mean the
real one introduced in 5.3) sucks.

It seems like you didn't read the whole RFC. The configuration is actually
very simple (just the command line options), and not meant to be a front-
facing HTTP server.

~~~
acabal
Off the top of my head, because when I want to reference
My.Namespace.MyClass.Foo(), I have to do something like:

    
    
      use \My\Namespace;
      $var = new Namespace\MyClass();
      $var->Foo();
    

I have to remember and type the parent namespace for every imported class I
want to use. In a big project this gets to be too much typing and too much for
my brain to remember. Contrast with say, C#:

    
    
      using My.Namespace;
      MyClass var = new MyClass();
      var.Foo();
    

You import a namespace, and the compiler figures out what goes where without
you having to remember anything.

Plus the weird exceptions required for backwards compatibility, and the global
namespace: I often forget where a root \ is required and where it isn't (not
when declaring a namespace, but often--not always!--when referencing one). And
of course there's the monstrous choice of namespace separator.

End of the world? Not really. Sucks? Yeah. And possibly a dealbreaker for me
for larger projects with complicated namespaces and lots of classes.

I'd love for this to be just a misunderstanding on my part, because it would
make my life a lot easier if PHP namespaces where more like C# ones!

~~~
ary
Your PHP example is possible to write in a way that is nearly identical to the
C# you provided. Why are you prefixing Namespace\MyClass(); when you declared
your namespace scope in 'use \My\Namespace'? Your assignment can just be:

    
    
      $var = new MyClass();
    

This brings it pretty much in line with your C# example. Have you read the PHP
docs on namespaces?

<http://www.php.net/manual/en/language.namespaces.basics.php>

~~~
acabal
That's the point; the PHP doesn't compile without the namespace prefix. In
fact I just tried it to make sure I'm remembering right.

~~~
ary
I was taken aback when I tested this for myself as my initial reading of the
PHP docs lead me to a very different conclusion. You are indeed correct, and
in my opinion that _is_ very broken. Touché.

------
al_james
I don't really see how this would help. Thats what FastCGI is for. You would
have to be dumb to expose a php internal HTTP server to the world, and
configuring a FastCGI backend is no harder than setting up a HTTP backend in
apache/nigix/whatever. If its just for testing, most apache installs come with
PHP by default, its just another command to learn.

~~~
abredow
Seems like the built in server would be most useful for newbies to get an
application running. Think if how much easier it is to get a basic Rails app
running to start learning compared to configuring Apache and PHP together.

~~~
al_james
Normally you just install apache and php and they just work. Macs come with
both pre-installed as do most linux distros. Don't see whats so hard!

~~~
abredow
It isn't too hard for someone who is already familiar Apache. On OS X, mod_php
is not enabled by default, requiring new users to dig in and learn about
apache config files and document roots. I'm not saying it is difficult, and it
is obviously important to learn, but it would be nice to be able to have a 1
page "get started with PHP" tutorial.

