On the Symfony Finland site there's a tutorial posted showing you how to run Symfony without a web server using Docker and PHP-PM.

Docker containers have been becoming an increasingly common deployment method in the past few years. I've deployed some Node.js app in containers, which are very simple to deploy as there's a single process that's easy to run. I found running PHP to be more complex.

[...] When running Nginx and PHP-FPM you are forced to run a pair of of containers, one for PHP-FPM and one for PHP-NPM. [...] But I would rather just run a single process to run the application. This is how Go, Node.js and even .NET Core apps are deployed. Can PHP do without a middle man?

While it may not be the most performant way to run a PHP and Symfony application, the author wanted to try it out and see how difficult it might be. The code for the setup is provided and, while the end result was a bit difficult to get to, it was possible.

Recently a major security vulnerability was announced centering around the the HTTP "Proxy" header and how incorrect handling could result in major issues with external requests. In the PHP ecosystem, a major HTTP library - Guzzle - was vulnerable (along with any application using it). However, according to Michael Dowling, a lead developer on the project, a new release has already been made to correct the problem.

httpoxy is a set of vulnerabilities that affect application code running in CGI, or CGI-like environments. It comes down to a simple namespace conflict [between the "Proxy" and "HTTP_Proxy" headers]. This leads to a remotely exploitable vulnerability. If you’re running PHP or CGI, you should block the Proxy header now. Here’s how.

The main HTTPoxy site as more information about how you can test to see if your application is vulnerable and what software/server configurations are typically vulnerable. There's also more language-specific information on the page as well as some immediate mitigations for various web server types.

The ProDevTips.com site has a tutorial posted showing you how to proxy requests with PHP on Ubuntu using Apache 2.4 and PHP version 5.4 or later.

I’ve just had to evade a Russian block of one of my employer’s sites, let’s call it CasinoX. Presumably they had blocked both www.casinox.com and www.casinox.com’s IP address (which is a Cloud Flare IP btw).

Simply pointing ru.casinox.com to the real IP address of www.casinox.com’s server was a not a viable solution though as that would expose the real IP publicly which is a no-go in the online casino business as it is basically an invitation to be DDoS’ed.

The solution they came up with was to set up a server that operates as a proxy and sends all traffic to the actual web server, save the assets (images, Javascript files, etc). They include the changes you'll need to the .htaccess configuration on the proxy server to forward the requests. Then they show the updated version of your virtual hosts configuration to match these changes. From there the rest of the handling lives in PHP. They include the code for the index.php proxy handling, a Proxy class that makes curl requests to the actual web server and an ip_in_range function to get the actual IP of the user/client making the request.

On the Symfony Finland blog there's a new post showing you how to serve PHP over HTTP/2 with HHVM and H2O. H2O describes itself as a "new generation HTTP server providing quicker response to users when compared to older generation of web servers".

This article is not about improvements made in HTTP/2 - as there are plenty of locations for you to read up on the internals. It's a hands on article to get started using HTTP/2 today with popular tools such as Symfony, WordPress and Drupal with the HHVM PHP runtime from Facebook. You can just as well use PHP-FPM.

They start with a bit of a look at the current state of PHP and HTTP/2 on the various major web server types. H2O, while younger, natively supports HTTP/2, he does offer the caveat that "waiting won't kill you". Despite this, they go on to show you how to set up the PHP+H2O+HHVM combination complete with configuration examples and what to look for in the logs to ensure HTTP/2 functionality.

On the Clancats.com blog there's a recent post showing how to create a web server in pure PHP, an interesting experiment but definitely not recommended for any kind of higher load situation.

Well, this is pretty useless, but it is possible. But again its pretty.. uesless. This tutorial will hopefully help you to better understand how a simple webserver could work and that it's no problem writing one in PHP. But again using this in production would be trying to eat a soup with a fork. So just, .... just don't. Let me shortly explain why this is not a that good idea.

PHP is a scripting language that simply is not really designed for such tasks. A webserver is a long running process which PHP is not made for. Also PHP does not natively support threading ( pthreads ), which will make developing a good performing webserver a really hard task.

He walks you through all the code needed to create the web server (also available on GitHub) by making:

• A "server" that does the listening for incoming and sends outgoing requests
• A request object that parses the incoming request and makes header and body content available
• A response object that allows for the setting of response codes, body content and headers
• Exception handling for problems encountered during the request/response process

The full code is provided during the process along with explanations of what each part does. There's also a basic introduction to what a typical web server is and how the process of request/response usually flows.

On DZone.com today there's a post covering the different kinds of handlers that can execute PHP - those pieces of code that work with the web servers we use every day to interpret and execute PHP code.

PHP Handlers? mod_php? FPM? How do we make sense of the inner workings of PHP outside of our lines of code? We know we can run PHP on the server to build web applications swiftly, but how can we optimize our environment and configurations to reach maximum scale? We know that PHP has its drawbacks for not being asynchronous or event-driven, which is all the more reason to ensure maximum optimization. The impact of your server environment on your PHP application performance can be more than you think you can afford. A careful examination of your PHP ecosystem will help you avoid suffering performance loss in areas you can otherwise solve for easily.

They provide a brief summary of what PHP handers, well, handle and where they fit in the overall architecture of execution. They then get into the details on some of them:

• CGI – mod_cgi
• suPHP – mod_suphp
• DSO – mod_php
• FastCGI – mod_fcgid
• FPM (FastCGI Process Manager) – php-fpm

Included in each is an overview of how it works and some of the main advantages (and disadvantages) of their use. He also mentions two of the most popular web servers that work with these handlers: Apache and Nginx.

In this new post to his site Mattias Geniar goes in circles...from Apache to Nginx and back in terms of how it relates to PHP.

As with many technologies, the PHP community too evolves. And over the last 6 or 7 years, a rather remarkable circle has been made by a lot of systems administrators and PHP developers in that regard.

He talks about the "early days" and the rise of Apache as the "A" in the LAMP stack. Then Nginx was created/released and PHP developers saw it as a viable option. He talks about how PHP worked with this server and the solutions that were found to "hack" them together. There were issues around the relationship, though, and - in the author's perspective - the circle has come back around to Apache, just with a bit more smarts about how it's configured.

Pascal Martin's latest post (in French, but the English version is coming soon) shares some statistics he's gathered around the usage of various software around the web, more specifically those involved in web-based applications.

I've collected statistics about the use of different PHP versions several times. The first time was in September 2011 and the most recent was in November 2013. At this point, PHP 5.2 still accounted for 34.4% of all PHP installations with PHP 5.3 moving up to 48.7%. This new data was collected the weekend of October 19th, 2014. At this point, the current stable versions of PHP are 5.4.34, 5.5.18 and 5.6.2. PHP 5.3 is no longer maintained (since August 14th 2014) and PHP 5.2 hasn't been supported for 4 years now.

He's broken up the statistics into a few different sections:

• Web server software
• Usage of major versions of PHP
• Usage of minor versions of PHP
• Versions in use under each of the major version numbers

He includes both the raw numbers (percentages) and some graphs showing the results in a bit more consumable fashion. It's interesting to see that, despite it being quite an old version now, PHP 5.3.x still has the largest share in the usage results.

UPDATE: He's posted the English version now as well.

In a new tutorial from the SitePoint PHP blog today Jeroen Meeus looks at a way to protect parts of your application from being used and abused. He shows you how to protect various parts of you site, including images and actual pages, with the help of either your web server or bits of code.

When building an awesome web app or website, we sometimes want people to be able to embed parts of our web app/website into their own. That could be an iframe holding a ‘like’ button, a simple image that they want to reuse or even our entire app embedded in an iframe. But how do we control who has access, who is allowed to use up our bandwidth and query our service? We define the problem as controlling access to assets. By assets we mean: anything that can be queried from our site.

He talks about the problem of "lifting" content and how to fall back to a "deny all, allow some" mentality. He starts with examples of Apache configurations that use mod_rewrite to only allow requests that come from the current domain (trusted) and the "files" directive coupled with Deny/Allow. He also includes an nginx example, showing the same request handling. The code examples show how to use PHP and Javascript to prevent access the same way.

The Master Zend Framework site has posted the first in their screencast series with a look at running the ZF2Skeleton with PHP’s built-in webserver.

In this screencast we’ll go through the creating an application from the ZF2Skeleton project on Github and getting it up and running, using PHP’s built-in web server. [It requires] PHP 5.4 or higher and Curl.

The screencast, coming in just over 3 minutes, briefly introduces you to the ZF2Skeleton project and shows you how to run it as a single process though PHP's own web server (useful for debugging). As a part of the installation, he also helps you get Composer installed as that's what Zend Framework 2 uses to install its packages correctly.