PHP Built-In Web Server(php.net)
php.net
PHP Built-In Web Server
https://www.php.net/manual/en/features.commandline.webserver.php
87 comments
Ad hoc (one line) HTTP static servers in various programming languages https://gist.github.com/willurd/5720255
It would be interesting if someone benchmarked them
They’re for dev purposes only; I think that would be testing for the wrong metric.
Thanks; I was looking for just this a couple of days ago.
Good to see a netcat one show up there --- it is capable of serving only a single file, and you need to prepend the response headers yourself, but it's been very useful the few times I've had to use it.
I"be seen netcat used to support oauth login in some shell scripts.
Missed a couple:
$ apache2
$ nginx
On practically any linux (or mac) you can do $ python -m http.server 8080 to instantly start up a server in that directory. You can do this in multiple terminals to have multiple servers on different ports serving multiple directories. Nginx, Apache require significant configuration and reboot to apply changes. They're not at all comparable.
How is it more of a burden to install apache2 vs sinatra? “Significant configuration” required for a static web server with apache2 is limited to just a few lines of configuration specifying the directory you want to serve and on what port.
Look, I love me an ad hoc HTTP server for development work, especially the one Python comes with, but calling it a one line web server is like calling “apt install postgres” a “one line database server”. It’a just not a one liner.
Look, I love me an ad hoc HTTP server for development work, especially the one Python comes with, but calling it a one line web server is like calling “apt install postgres” a “one line database server”. It’a just not a one liner.
That comes really handy when you want to, say, transfer some files from your PC to your phone/tablet without uploading them somewhere else first.
Apache usually just needs to reload the config file not reboot, and it's also often only a few lines to get whatever you want done. Reload might take 1/2 a second, but I doubt it takes even that long. Sure, if you want to load a module with a bunch of new functionality you might need the 2 seconds it takes to reboot unless you have thousands of sites, but that has been a rare experience in the last 7 years or so for me. If you have thousands of sites you are not using python server anyway. In the end apache config is relatively easy -- especially to just test stuff quickly --, it's the overall server security that is more nebulous due to the variety of attack vectors throughout the stack. I would guess all that is similar on Nginx.
So sure, it is a little easier to just throw out a one liner, but it doesn't give you an environment that is similar to deploy, so the extra 2 minutes to open the apache config and reload is worth it to me for the implicit bug testing going on. Of course none of us has a horse in the race and to each his own on his own box. But it's fair to keep their names in the conversation at least.
So sure, it is a little easier to just throw out a one liner, but it doesn't give you an environment that is similar to deploy, so the extra 2 minutes to open the apache config and reload is worth it to me for the implicit bug testing going on. Of course none of us has a horse in the race and to each his own on his own box. But it's fair to keep their names in the conversation at least.
No, these don’t have configuration files and can be set up from the command line arguments.
One of these is literally installing sinatra. And if you just want a server to serve static assets, nginx or apache2 will happily serve it out of your /var/www. Symlink what you want there and you don’t have to edit any config files or anything.
> 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.
It's also pretty slow. I use it in development sometimes, and it easily blocks on a single long request.
Works fine for development though, or if you want a quick and dirty solution to send a large file to a smartphone (or whatever).
Works fine for development though, or if you want a quick and dirty solution to send a large file to a smartphone (or whatever).
Looks like that as of 7.4 it supports multiple workers for concurrent request handling.
Want to bet some people will integrate this into their "prod" Docker containers?
I smell a Medium article coming up.
This built-in server has been around since March 2012. If there are any Medium articles to be written, they're probably out there already.
Titled "5 Reasons you don't need Apache/nginx anymore", filled with misinformation, and a comment section full of people ripping it apart.
Or at least that's been my experience with Medium since I started using it a few months ago.
Or at least that's been my experience with Medium since I started using it a few months ago.
I bet people won't. Ready-made docker solutions are based around nginx/apache and shared hosting stacks were in place long before php built-in webserver was available. There's no reasons and incentives to change all that.
“A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools.”
― Douglas Adams
― Douglas Adams
This web server has been available for a long time. Sure you can misuse pretty much any technology. Rolling your own crypto is possible too but most people don't do it.
People tend to use ready-made Docker containers for PHP deployment. The official PHP image has apache and fpm versions: https://hub.docker.com/_/php/
People tend to use ready-made Docker containers for PHP deployment. The official PHP image has apache and fpm versions: https://hub.docker.com/_/php/
Most of the enterprise world (which still accounts for far more code in production than startupland) doesn't use Docker.
But they also don't use this web server. I don't think I've ever heard of anyone using this web server, actually, even for development.
But they also don't use this web server. I don't think I've ever heard of anyone using this web server, actually, even for development.
Yup. With the way how php has being deploying over the last 20 years I wouldn't be surprised.
It is also single threaded. One would see serious performance issues if one tried to use this in production with any significant traffic.
This is really cool for making local apps which have a web-ui instead of gtk/electron based ui.
I've been using this in a lot of small tools(1) where I use this server to load the web-ui in the browser and a PHP script for file IO.
(1) https://github.com/san-kumar/kanban
(2) https://github.com/san-kumar/devtodo2-web-extension
I've been using this in a lot of small tools(1) where I use this server to load the web-ui in the browser and a PHP script for file IO.
(1) https://github.com/san-kumar/kanban
(2) https://github.com/san-kumar/devtodo2-web-extension
I wouldn't rely on the PHP WS, it's a bit of a buggy crapshot and loves to crash when encountering complicated errors.
I've been doing this with singe file html pages that bundle all dependencies inline, no server necessary. It does put some restrictions on what you can do, since local files are sandboxed pretty hard, but with all dependencies inlined (and with WebAssembly you can get pretty crazy, like embedding SQLite in an html file) you can do quite a lot.
Just the other week I made a little app that loads CSV files from a room booking system to create monthly reports, which was done manually by the sole employee of our housing association and took several hours – now it takes minutes.
It's been my go to way to create easily deployed rich GUI apps for the past year or so, and is pretty simple to build with a few shell scripts to put it all together. The resulting html files can be big, but they load really quite fast and since they're deployed on to a machine and not served over a network the size doesn't matter that much. It's also way less than an electron deployment anyway.
Just the other week I made a little app that loads CSV files from a room booking system to create monthly reports, which was done manually by the sole employee of our housing association and took several hours – now it takes minutes.
It's been my go to way to create easily deployed rich GUI apps for the past year or so, and is pretty simple to build with a few shell scripts to put it all together. The resulting html files can be big, but they load really quite fast and since they're deployed on to a machine and not served over a network the size doesn't matter that much. It's also way less than an electron deployment anyway.
What is the tooling and workflow you use for this? It's not something that had occurred to me, but now that you mention it, it seems like something I'd like to try.
Edit: It looks like none of the major bundlers support this feature out of the box, but there is a project called in inliner that does exactly this: https://github.com/remy/inliner
Edit: It looks like none of the major bundlers support this feature out of the box, but there is a project called in inliner that does exactly this: https://github.com/remy/inliner
Nothing fancy, just a few home grown shell scripts to essentially replace external dependencies in the html (e.g. script tags or link tags) with the contents of those files. There's no minifying, optimization, or building or anything. I only use vanilla js, css and html. The only exception to this is if I have anything that needs compiling to wasm, which essentially is just SQLite, but could be anything really.
Because I only deploy these locally on desktops it's pretty much pointless to build/obfuscate/optimize anything for transport, it's so fast to load anyway since it's all off the local drive.
Maybe I should write up a how-to or tidy up the workflow and publish, but it's really nothing fancy.
Because I only deploy these locally on desktops it's pretty much pointless to build/obfuscate/optimize anything for transport, it's so fast to load anyway since it's all off the local drive.
Maybe I should write up a how-to or tidy up the workflow and publish, but it's really nothing fancy.
I was heavily into PHP in the late 90s and early 00s, including hosting download mirrors, then left it for years for other tech in non-server areas. I got back to it recently to start playing with Micropub implementations and other indieweb stuff and was pleasantly surprised to find this server in there. It’d been a long while since MAMP and configuring Apache for me so it was nice to just not have to worry about unearthing that stuff again and hit the ground running on the actual software.
Oh man, this sucker. I did some filthy stuff in a legacy PHP codebase using this to get some ultra basic acceptance and smoke tests in place. It worked fairly well, but there were a lot of weird edge casees where it didn't _quite_ work like a real webserver. I've got some notes hiding on an old laptop, I should dust those off and post them up sometime.
I use this to host a small WordPress blog on my server whenever I want to make changes that I then compile into static HTML for public access. Works well enough and avoids the need to lock down a public WordPress instance.
So you just fire it up whenever you need to login and write a post, and then shut it down or?
What are you using to generate the static html?
I've used a plugin called WP2Static to turn WP sites into static HTML. You can also use WGET to crawl the site and export HTML, but it requires some tinkering. Google "export Wordpress to HTML using WGET" to find some walkthroughs.
That's what I use too. It's completely open source and works pretty flawlessly for simple stuff like this.
Thanks, I'll give it a try.
I am familiar with wget, curl and some browser plugins that can scrape a site. A WordPress plugin should be able to give you some extras, especially when you start to think about things like responsive designs.
I am familiar with wget, curl and some browser plugins that can scrape a site. A WordPress plugin should be able to give you some extras, especially when you start to think about things like responsive designs.
"You can configure the built-in webserver to fork multiple workers in order to test code that requires multiple concurrent requests to the built-in webserver."
The built-in web-server itself was released with PHP 5.4 (2012). The only thing new about it is support for multiple workers to make it faster for concurrent request handling. But, it's still only intended for development environment and testing. I imagine multiple-workers support is very useful with SPA development, and especially improves testing speed if you run concurrent tests that rely on built-in web-server.
The built-in web-server itself was released with PHP 5.4 (2012). The only thing new about it is support for multiple workers to make it faster for concurrent request handling. But, it's still only intended for development environment and testing. I imagine multiple-workers support is very useful with SPA development, and especially improves testing speed if you run concurrent tests that rely on built-in web-server.
this is pretty old, why is it on the frontpage now?
Apparently it's news to many
Because ZnZirconium only learned about this today → https://xkcd.com/1053/
"I was today years old when I found about it"
In a previous post about PHP, people were complaining that you still require nginx or Apache. I guess OP found this while looking for an alternative.
because the are people that run MAMP/WAMP in a production environment?
I'm curious, what's wrong with this?
but this is for dev only
>It is not intended to be a full-featured web server. It should not be used on a public network.
>It is not intended to be a full-featured web server. It should not be used on a public network.
That's my point. So is MAMP/WAMP. The devs have always stated their setup was meant for development only, yet lots and lots of novices use a MAMP/WAMP setup as their production environment.
I'm considering adding something like this to https://expose.sh to serve static sites (like React apps) publicly in one command.
Something like:
expose serve public
Your site is ready at https://a3rd.expose.sh
Then your static side would be served from localhost over a public URL which you could then use for demos (or helping your backend guy do the integration). This wouldn't be too difficult to implement.
Something like:
expose serve public
Your site is ready at https://a3rd.expose.sh
Then your static side would be served from localhost over a public URL which you could then use for demos (or helping your backend guy do the integration). This wouldn't be too difficult to implement.
Are there any major differences between expose and ngrok? Why would I choose one over the other?
Expose focuses on http and https whereas ngrok supports all kinds of protocols like SSH etc.
This makes the syntax a bit simpler instead of "ngrok http 80" it's "expose 80".
If I added this "expose serve" feature that would be one thing it could do that ngrok can't as yet
This makes the syntax a bit simpler instead of "ngrok http 80" it's "expose 80".
If I added this "expose serve" feature that would be one thing it could do that ngrok can't as yet
Expose is much cheaper.
Correct. Month to month it's about the same, but no minimum subscription term.
The PHP built in web server is useful in development. It's not intended for production. Good for getting a quick example running locally
I love PHP's buildin web server than other languages for quick use because its command line is quite easy to remember.
php -S localhost:8080
php -S localhost:8080
On Linux, php -S 0:8080 is shorter if you're just testing (as it's meant for) and have a firewall - though it opens it for 0.0.0.0 (anyone who can reach your system).
Not sure about other OSes, I think I noticed this doesn't work on Windows once but that could also have been BSD or something.
Not sure about other OSes, I think I noticed this doesn't work on Windows once but that could also have been BSD or something.
While not built into node, I like "serve" best in terms of syntax, even if it only supports static sites.
serve . Done
serve . Done
This sounds like a perfect solution to self-hosting websites (e.g. wiki, grocy, monica) that's protected by an identity-aware proxy (e.g. Pomerium) that are expected to receive <1qps traffic.
(Most of my self-hosted web services are written in Go, I've being able to stay nginx-free thanks to Go's built-in web server.)
(Most of my self-hosted web services are written in Go, I've being able to stay nginx-free thanks to Go's built-in web server.)
I don't get it. This is since 5.4 which is like 6 years ago.
I wonder if the 'news' is the 7.4.0 change that allows for configuration for multiple concurrent requests, by spinning-up numbers of workers as needed?
/well this will help when running it from a docker container.
Absolutely, but you should probably only do it for development. As they write on the linked PHP manual 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 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.
That was my thought too (the sarcasm). This was amazing when it was introduced, but in the age of Docker it's no longer really relevant to bootstrapping a basic dev environment.
It is still nice for quickly running something and get rid of it. For instance an ad-hoc script mocking an API endpoint that you can run on an arbitrary port in seconds.
PS: a few years ago docker was not deemed production ready, and people only used it as dev/testing environment. I find it funny that the reverse is sometimes happening, where people prefer running this webserver locally for speed and eventual debugging, while production runs on containers.
PS: a few years ago docker was not deemed production ready, and people only used it as dev/testing environment. I find it funny that the reverse is sometimes happening, where people prefer running this webserver locally for speed and eventual debugging, while production runs on containers.
> It is still nice for quickly running something and get rid of it. For instance an ad-hoc script mocking an API endpoint that you can run on an arbitrary port in seconds.
That is one of the many things Docker and Docker Compose are good at. If you have a docker-compose.yml file you can do just that with any web server backend.
That is one of the many things Docker and Docker Compose are good at. If you have a docker-compose.yml file you can do just that with any web server backend.
Say you wrote your 10 lines script that mocks your third party endpoint.
running it on port 7659 is
> php -S 0.0.0.0:7659 scripts/test.php
and done.
Compared to this one liner, the proposition is making a dockerfile with a base image, perhaps your local extensions if you had to compile them, and configuration if you changed from the default one.
Then a docker-compose to share your local file, which references the previous Dockerfile, and specifies the right port. Knowing if your testfile is not self contained, you’d need to map any services it needs to access to.
Then you run the whole.
It is by no mean complicated, and you could keep around a template of all of that around in case you need it (or you copy it from your main application’s docker files, and modify if you need to it more lax). As you say it also gives you more freedom. It’s just a tad more tedious than literally one line.
running it on port 7659 is
> php -S 0.0.0.0:7659 scripts/test.php
and done.
Compared to this one liner, the proposition is making a dockerfile with a base image, perhaps your local extensions if you had to compile them, and configuration if you changed from the default one.
Then a docker-compose to share your local file, which references the previous Dockerfile, and specifies the right port. Knowing if your testfile is not self contained, you’d need to map any services it needs to access to.
Then you run the whole.
It is by no mean complicated, and you could keep around a template of all of that around in case you need it (or you copy it from your main application’s docker files, and modify if you need to it more lax). As you say it also gives you more freedom. It’s just a tad more tedious than literally one line.
That's a fair use case, although I might still wrap that one-liner in a Docker container because the service consuming the mock is probably Dockerized. But indeed it doesn't make sense to configure and run another nginx container just for that 10-line mock.
Because apparently the only relevant people are those who have taken on the complexity of running docker?
I'm literally blown away by this comment.
I'm literally blown away by this comment.
> runs only one single-threaded process
I'm pretty sure that PHP-FPM is a better choice.
I'm pretty sure that PHP-FPM is a better choice.
php is great and this is not news. all the haters go to your hipster frameworks and spend the time i need to build an app with just setting up your boilerplates.
As this apparently has been around for a while, hows the security of this server?
The node examples can be true one liners if you use npx
I have an absolute hatred of putting unused code on a production server, especially if it's something that can listen to network traffic. It's such an unnecessary risk. The fact that you don't appear to be able to set PHP up in a way that disables the use of this thing feels horrible. There's no way I'd ever want to run PHP outside of a container that I have control over which few ports are mapped to now.
Time to take some medication maybe? Such hatred against programming language is not normal.
I don't hate the programming language. PHP is a great language that I used for a decade before moving over to the frontend. I don't use it any more but I work in a company that does and I see good results when it's deployed. This is not about PHP (or Python, or Ruby, as they also have built-in httpd servers).
What I hate is the idea of putting something on a server that's going to make my life harder, or create more work for my team. I don't want the developers I work with having to give up their evenings or weekends to resolve issues and incidents that arose from things shouldn't have existed in the first place. That's why I don't want additional network services sneaking their way on to production. I should very easily be able to tell which applications on a server are listening to external traffic.
Maintaining good security is hard enough without language runtimes including things that should strictly only ever be a development dependency rather than a production dependency.
If there are pills I can take to make this problem go away, sign me up.
What I hate is the idea of putting something on a server that's going to make my life harder, or create more work for my team. I don't want the developers I work with having to give up their evenings or weekends to resolve issues and incidents that arose from things shouldn't have existed in the first place. That's why I don't want additional network services sneaking their way on to production. I should very easily be able to tell which applications on a server are listening to external traffic.
Maintaining good security is hard enough without language runtimes including things that should strictly only ever be a development dependency rather than a production dependency.
If there are pills I can take to make this problem go away, sign me up.
How does a feature of the Command line version of php impact developers? Developers should not run applications on production machines themselves (either its a script, a deployement agent / engine or a operations guy that does that work (including devops guy with operations)).
As for security you must keep up with the capabilities of the tools you use. Php has been able to run as a webserver for years (even before 5) all they did is implement a good sane dev server to run php code without setting up a complex php environment (that is probably less secure).
As for security you must keep up with the capabilities of the tools you use. Php has been able to run as a webserver for years (even before 5) all they did is implement a good sane dev server to run php code without setting up a complex php environment (that is probably less secure).
honestly, I would never run anything important in production that's not behind a load balancer+firewall, so without direct internet access. it helps with upgrades, as you can upgrade separately each node without putting down the application and it provides security because you only whitelist what you want to give external access (yes, I know there are still other attacking vectors, but still, security is an incremental job that adds on layers and layers of best practices)
This is only present in the CLI builds of php, And you should limit who can run the php scripts anyway on a production server.
Remember that setting up a reverse shell only requires a networkable shell (like bash). Most linuxes (including containers) there for have the capability of having reverse shells started on them. The way to protect abuse of PHP’s webserver function is the same as the one to protect against bash reverse shells. Do not allow any outbound traffic but only traffic you trust!
Do not blame php for having a feature that others have had for years. PHP’s version is no better or worse than any of them.
Remember that setting up a reverse shell only requires a networkable shell (like bash). Most linuxes (including containers) there for have the capability of having reverse shells started on them. The way to protect abuse of PHP’s webserver function is the same as the one to protect against bash reverse shells. Do not allow any outbound traffic but only traffic you trust!
Do not blame php for having a feature that others have had for years. PHP’s version is no better or worse than any of them.