PHP Built-in web server(php.net)
php.net
PHP Built-in web server
http://php.net/manual/en/features.commandline.webserver.php
13 comments
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).
> 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.
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.
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?
I thought I made that pretty clear with the opcode cache example. On the first request to a specific URL the script gets compiled, executed and cached. On the second request we skip the compile part and point the executor to the op_array in shared memory. We could do some hackish things where we try to persist that shared memory segment for the cli case, but that would be another artificial environment. We want to test as closely as possible to real production use cases and the best way to do that is to use an actual web server for any tests that rely on anything persisting across requests.
> 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.
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.
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).
As a slight aside, I wonder if you would consider putting your name and/or relationship with PHP in your profile (particularly as you use "we" and "our" in relationship to PHP). It might help newcomers appreciate the particular (valuable) insight into PHP in your posts and put them into better context.
It took me a while of reading your posts on here to realize who you were, and I note in a recent thread someone even asking how you learned so much about how PHP works...!
Please keep commenting on PHP threads here, the balance and insight is very much welcome!
It took me a while of reading your posts on here to realize who you were, and I note in a recent thread someone even asking how you learned so much about how PHP works...!
Please keep commenting on PHP threads here, the balance and insight is very much welcome!
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.
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.
> I do agree that this should probably not be in the core php interpreter, though.
It isn't.
From the page:
"As of PHP 5.4.0, the CLI SAPI provides a built-in web server."
It's part of the CLI SAPI. That's the command line interface to the PHP interpreter. Which makes sense, since that's the only place you'll use it. So if you're using CGI, FastCGI, Apache module, or any other SAPI for regular PHP work, that code is not being loaded.
I'm also pretty sure you can turn it off during compilation of PHP, making it easily removable.
It isn't.
From the page:
"As of PHP 5.4.0, the CLI SAPI provides a built-in web server."
It's part of the CLI SAPI. That's the command line interface to the PHP interpreter. Which makes sense, since that's the only place you'll use it. So if you're using CGI, FastCGI, Apache module, or any other SAPI for regular PHP work, that code is not being loaded.
I'm also pretty sure you can turn it off during compilation of PHP, making it easily removable.
Yep, you can turn it off:
./configure --disable-cli
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.
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.
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.
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?
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?
I upgraded my local Ubuntu install to PHP 5.4 solely to take advantage of this.
We write Rails apps at work mostly these days, but still have some PHP apps floating around.
Now, instead of having to configure something like Apache just for local development, I've added Procfiles for Foreman to these projects for firing up the PHP webserver along with the rest of the processes the app needs. Much nicer, much more in line with what I enjoy over in Rails-land every day.
We write Rails apps at work mostly these days, but still have some PHP apps floating around.
Now, instead of having to configure something like Apache just for local development, I've added Procfiles for Foreman to these projects for firing up the PHP webserver along with the rest of the processes the app needs. Much nicer, much more in line with what I enjoy over in Rails-land every day.
Seriously. How great is it that anyone with PHP installed can get up and running from a git repository in literally 3 commands?
[deleted]
[deleted]
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.
This built-in web server has singlehandedly influenced me to actually look at using PHP for projects.
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.
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
I like it is like in the rails/django world
"I like it is like in the ruby/python world"
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
edit: removed completely presumptuous gender pronouns
Yeah, but setting up a rails or django server/hosting environment for development is a lot more difficult than a comparable php setup; tools like MAMP, XAMP, et al make it fairly trivial to get going quickly.
> pip install django
> django-admin.py startproject myproject
Is that really so hard?
> django-admin.py startproject myproject
Is that really so hard?
You need pip first, especially if you're on Windows, which I'd imagine is a little more difficult than just installing XAMPP with an .exe.
XAMPP/MAMP and others like it seem like they make life easier until you hit a point where you realize that they are seriously leaky implementations. I wish I had time to write in detail about this (because I also hate when people make claims like this without showing examples); however, I have a feeling that the people that would benefit the most won't care anyway.
Don't these distros still put php.ini in c:\windows?
Don't these distros still put php.ini in c:\windows?
nope.avi
You need mysql-python, which depends on some header from mysql-client-dev, which requires some compiling or package, then there's PIL, virtualenv, uwsgi and shit.
Oh wait, you don't have pip on most distros by default. You need to apt-get or wget that.
You need mysql-python, which depends on some header from mysql-client-dev, which requires some compiling or package, then there's PIL, virtualenv, uwsgi and shit.
Oh wait, you don't have pip on most distros by default. You need to apt-get or wget that.
For smaller projects, sure, this is great. The moment you need to test your site with the the Apache rewrite_module or another web servers flavor of it is the moment this becomes useless.
Yeah but if you need that functionality you can take the hour to set up a localhost install of apache with whatever stuff you need. This is for rapid debugging and people just learning.
I am a huge fan of XAMPP/LAMP for exactly this reason!
Exactly, and I like built in servers because it's easy to start messing with stuff until I find I need something bigger (and I often don't until it's time to actually think about deploying stuff). I can't even think of the number of times I had an idea, started installing a server to work on and stopped halfway through.
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.
His reply on this thread http://news.ycombinator.com/item?id=4502041
Oops didn't see that he had already posted that.
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.
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.
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.
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).
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).
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
This isn't intended for production use.
PHP-FPM is, though, and it's been around for quite some time.
PHP-FPM is, though, and it's been around for quite some time.
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.
Well that could come in pretty handy.
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.
Core language features? Oh, you mean like all these guys? http://nikic.github.com/2012/07/10/What-PHP-5-5-might-look-l...
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?
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?
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.
There is nothing stopping others getting involved if there were other things they want to see in future PHP versions.
> how you allocate that manpower
This is open source. You don't "allocate" manpower - people work on whatever they find interesting.
This is open source. You don't "allocate" manpower - people work on whatever they find interesting.
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.