They start with the HTTP side of things, briefly covering what HTTP messages are and the format they're transmitted in. Using some example curl requests they show requests and responses involving normal responses, redirects and how they're broken down into objects implementing the MessageInterface, RequestInterface and ResponseInterface. They outline the PSR-7 specification in a UML diagram and talk about some of the challenges associated with PSR-7's handling (including the use of immutable objects and how it fits in with middleware handling).

The post ends with a listing of a few of the frameworks/libraries that already make use of the PSR-7 structure including Symfony, Slim, Guzzle and the HTTPlug client.

The PHP Town Hall podcast has posted their latest episode (after a bit of hiatus) giving the low down on PSR-15, the proposed PHP-FIG standard for HTTP middleware.

n all star cast this episode, as Ben and Phil are joined by regular guest Anthony Ferrara - thinker of good ideas and long-time part-time side-line contributor to the PHP-FIG, Woody Gilk - one-speed rider & BDFL of Kohana, and Beau Simensen - author of a bunch of stuff including StackPHP.

Here we’re talking about some awesome stuff the PHP-FIG is working on: PSR-15 (HTTP Middleware). [...] We discuss all this, and the reason PSR-7 (HTTP Message) is not enough for the ecosystem to benefit from shareable middleware. [...] Woody provides a bit of the decision-making process in a very tricky aspect of the FIGs job, which is: should standards be built entirely to match existing implementations, or should standards try to improve on the learnings of the existing implementations to better them all as implementations change to support the standard. It’s all a bit chicken and egg, but a very worthy discussion to have.

In a new post to his siteAlex Bilbie looks at a good approach to simplifying the OAuth 2 authorization flow for a device and some of the simple PHP that can power it.

When signing into apps and services on devices such as a Playstation or an Apple TV it can be immensely frustrating experience. Generally you will ordeal something similar to one of the following scenarios: The utterly terrible experience whereby you don’t have anything other than an onscreen keyboard [or] A slightly less terrible experience whereby you can pair a bluetooth keyboard to enter your username and that crazy long password.

[...] There are some apps however - such as Youtube for Apple TV - that have a much better end user experience.

He talks more about this better experience involving a simple code presented to the user, a special URL to link the device and the typical OAuth-ish authorization page to link the request to your account. He then explains how it would work with a PHP backend: making the request to the auth server, returning a message with the codes and URL to pass along and the "device code" it responds with. He also includes a few examples of error responses for polling too quickly, pending authorization and a denied request. This is all based on the (currently in draft) OAuth 2.0 Device Flow Grant currently in the works.

The end goal here is to have an application that will send a simple Hello World message. So we’re going to cover the core framework stuff, but save things like templating, database access, ORMs, and forms for later. The goal here to see how to scaffold a Symfony app to better understand why symfony standard does what it does and where to deviate. We’ll end up with an app that uses the Symfony 3 directory structure.

Starting with the smallest "composer.json" he can (just symfony/symfony) he walks through the creation of the application one step at a time:

The Application Kernel

Handling Web Requests

What’s in a Bundle?

Stepping into Configuration

AppBundle

Hello, World

The end result is a simple page outputting a "Hello, World" message, but it gives you a good foundation to work from and understanding of the simplest pieces needed to make a Symfony application.

The road to PSR-7 was a long and winding one. It started in summer of 2012 as a draft proposal on HTTP clients by Benjamin Eberlei, during which others proposed that perhaps a smaller standard on the HTTP message interfaces themselves — which would also allow targeting server-side applications, as those rely on the messages.

He follows the proposal's flow through the PHP-FIG process, pointing out several others who contributed along the way and what changed along the way. He also includes a section of thanks for some of the other developers and PHP-FIG members that made contributions along the way.

On the This Programming Thing blog there's a recent post showing you how to define your own "sniff" settings for the popular PHP_CodeSniffer tool. The codesniffer lets you define standards that need to be in place for all code in your application and notifies you of violations.

At Zimco, we’ve started working on standardizing our coding but we ran into a little problem while we tried to automate the process of making sure our code adhered to that standard. [...] I think we get into our own way of doing things and everything else is wrong. This code makes me feel irrationally angry (so angry I’m having a hard time not fixing it…). Ultimately, the best way to fix these kinds of formatting problems is to sit down and discuss what’s best and have everyone stick to the same set of standards.

They talk some about the place for PSR in coding standards (specifically PSR-2) and the fact that there's already "sniffs" provided to check against those rules. However, they point out that running this against a non-PSR-2 codebase can be a mess and show you how to customize your own standard to more match your current state. They use an XML configuration file to update the tab width setting to four spaces and then apply the PSR-2 standards. They also show how to exclude certain rules and mention a handy plugin you can use in Sublime Text to keep your code within standards.

The voting phase for the PSR-7 proposal (HTTP messaging structure) has been cancelled due to the desire to improve and clarify the spec before approving it.

Since we put PSR-7 up for a vote, a number of issues have arisen that we feel require attention. In most cases these are clarifications that, had they been made during REVIEW, could have been merged without dropping the spec back to DRAFT. Sadly, since PSR-7 is now up for a vote, we cannot make clarifications to the spec. We cannot even make clarifications after the spec is accepted, either, except by way of annotations and errata in the meta document.

We've weighed the risk of leaving the spec as-is against canceling the vote and making the required changes directly to the spec itself. This has been an ongoing discussion since the middle of last week. I had a meeting with Mathew and Paul this morning in which we decided that it would be in the best interest of everyone for us to cancel the vote and make the changes directly.

The call was a tough one, but the discussions around the proposal have worked out a lot of the kinks, just not all of them. As is mentioned in the Google Groups post, the PSR will go back up for a vote in two weeks. PSR-7 outlines a standardized interface for working with HTTP requests and responses, providing interoperability between frameworks and tools at this basic level.

Evert Pot has written up a new post today with some of his thoughts about what's wrong with the PSR-7 proposal in the PHP-FIG. PSR-7 relates to a standardized interface for HTTP request and response handling.

PSR-7 is pretty close to completion. PSR-7 is a new 'PHP standard recommendation', put out by the PHP-FIG group, of which I'm a member of. [...] PSR-7 gets a lot of things right, and is very close to nailing the abstract data model behind HTTP, better than many other implementations in many programming languages.

But it's not perfect. I've been pretty vocal about a few issues I have with the approach. Most of this has fallen on deaf ears. I accept that I might be a minority in feeling these are problems, but I feel compelled to share my issues here anyway. Perhaps as a last attempt to sollicit change, or maybe just to get it off my chest.

He breaks up his thoughts into a few different categories, each with a summary and sometimes some code to help make his point a bit more clear. He talks about immutability, how objects will be immutable and shows an example of change in how Silex would have to function to follow the standard (with before/after). He then goes on to talk about the "issue with streams" and how the current proposal could allow for changing of the incoming request into a new one with new headers...not immutable. He ends the post talking about PSR-7's stance on buffering responses and how, even if his project doesn't adopt the PSR in the strictest sense, they may still take some inspiration from it.

Pádraic Brady has a new post to his site today talking about a security-oriented PSR that's being proposed to the PHP-FIG group (by Lukas Smith). The proposal suggests the creation of a security policy to be used by members of the PHP-FIG and a way to make sharing security issues more standardized.

Lukas Kahwe Smith recently brought forward an idea to PHP-FIG with two broad objectives for a new PSR: To write a security policy that could be adopted by members; and proposal to make sharing security vulnerabilities more common and standardised. He has invited interested people to express their interest in joining a separate mailing list to discuss the details: https://groups.google.com/forum/#!topic/php-fig/45AIj5bPHJ4. Larry Garfield of Drupal and Korvan Szanto of concrete5 CMS have offered to sponsor the proposal.

He talks some about security policies in general - what they are, why they're a good idea and what Lukas is proposing for PHP projects. He also briefly covers the publishing of vulnerability data, the different options for publishing them and how the standardization of it could be integrated with current tools (Composer anyone)?

Michael Dowling has a new post today with a new tool he's worked up that aims to make creating Changelogs simpler, building on the effort started by keepachangelog.com. A Changelog is a human-readable listing of changes between versions, ideally generated but usually manually created.

Open source projects often include some kind of changelog file that helps consumers of the project know the important changes that have been made between versions. The format and filename of a changelog typically varies from project to project; however, there’s some promising news…http://keepachangelog.com hopes to standardize how open source projects represent changelog files. I’ve recently begun modifying the changelog files of all of my projects to conform to this new changelog standard.

He then gets into the tool he's created, chag, and how to aims to help make this Changelog standardization even easier. He walks you through the installation and options it provides for extracting current contents, listing versions, getting the latest versions and updating the contents. There's also an option to tag the version with a Git tag and uses the entry data as the annotation. He then talks about the release process with two different flows: the one GitHub itself includes (GitHub Releases) and the other configured through Travis CI.