Interview with Katie McLaughlin

planet PHP - 2019-09-11(水) 08:03:00
カテゴリー: php

511 Network Authentication Required

planet PHP - 2019-09-11(水) 00:00:00

511 Network Authentication Required is a status that can be used by for example captive portals to signal to computers that they need to go through some kind of sign-in after connecting to a WiFi network.

You might see these kind of sign-in screens when for example connecting to the WiFi at a coffee shop.

Most operating systems and browsers detect this log in screen by making a HTTP request to a standard url. These are some real examples:


Browsers and operating systems will do an HTTP request to one of those urls, and expect a string like success to appear. If it doesn’t appear, it means a router might be blocking it and a pop-up will appear to log into the network.

One of the issues with this approach is that it might not be possible to for a client to distingish a ‘correct’ response, vs. a HTTP response that was intercepted by the network and a captive portal being served instead.

It is a type of man-in-the-middle attack, so returning a captive portal interface instead of the real response might cause systems to malfunction and caches to be primed with bad data.

The 511 Network Authentication Required status code was invented as a default status code for captive portals to return when intercepting a HTTP request. This status signals that it was returned by an intermediate.

The full HTTP response should contain a link to where the user may log in.

The example given from the RFC is as follows:

HTTP/1.1 511 Network Authentication Required Content-Type: text/html <html> <head> <title>Network Authentication Required</title> <meta http-equiv="refresh" content="0; url="> </head> <body> <p>You need to <a href=""> authenticate with the local network</a> in order to gain access.</p> </body> </html> References
カテゴリー: php

Interview with David Bisset

planet PHP - 2019-09-10(火) 20:30:00
カテゴリー: php

Xdebug Update: August 2019

planet PHP - 2019-09-10(火) 17:25:00
Xdebug Update: August 2019
London, UK Tuesday, September 10th 2019, 09:25 BST

This is another of the monthly update reports in which I explain what happened with Xdebug development in this past month. It will be published on the first Tuesday after the 5th of each month. Patreon supporters will get it earlier, on the first of each month. You can become a patron here to support my work on Xdebug. More supporters, means that I can dedicate more of my time to improving Xdebug.

In August, I worked on the following things:

2.8.0beta2 Release

This second beta release addresses a lot of issues that were still outstanding for the 2.8 release. This included simple issues like Wrong name displayed for Recoverable fatal errors and Code Coverage misses fluent interface function call. The trickiest bug was related to the DBGp debugging protocol.

I test Xdebug's implementation of the DBGp protocol by having a file with the PHP script to debug and then a phpt test that has a set of commands to run against that file. As an example, for one of the fixed bugs, the script looks like:

<?php function breakpoint1() { echo base64_encode("testing"), "\n"; strlen(); } breakpoint1(); ??>

And the phpt test looks like:

<?php require 'dbgp/dbgpclient.php'; $filename = realpath( dirname(__FILE__) . '/' ); $commands = array( 'feature_get -n resolved_breakpoints', "breakpoint_set -t line -f file://{$filename} -n 4", 'breakpoint_list', 'feature_set -n resolved_breakpoints -v 1', 'feature_get -n resolved_breakpoints', 'breakpoint_list', "breakpoint_set -t line -f file://{$filename} -n 4", 'breakpoint_list', 'detach', ); dbgpRunFile( $filename, $commands ); ??>

The third command sets a breakpoint on line 4 (the echo statement) and then does various things related to breakpoint resolving. The "remote log" that is generated by the test is then compared (after some regexp replacements) with the expected output.

Because I run the script in a new process, I have some methods in place to also collect the output of the script (both stdout and stderr). I don't usually have stderr on, as there are a few false positives, but when I tested with this in the past, I noticed that one test caused a segmentation fault.

After a few hours of trying to find out the problem, I noticed that this would only happen in the init state (when the debugger first connects to the IDE, and when the IDE can enable features and send breakpoints). If in this init state the IDE would send the detach command, Xdebug would crash. This detach command can be used by an IDE to disengage the debugger, with the script continuing to run afterwards.

Due to an implementation bug related to whether the debugger connection was active or not, a detach in the init state would mark the connection active, while the connection was already cleaned up before hand. This caused Xdebug to access memory, that was already freed (which is a bad thing to do). The fix was luckily quite simple.

IANA Port Assignment

As a result of a twitter conversation that I had, I tried applying for an "assigned port" for the DBGp protocol. As some of you might be aware, Xdebug shares the same default port (9000) as PHP-FPM. This has caused confusion in the past, so I was hoping to avoid future problems with Xdebug 3 by asking IANA to assign me one. However, IANA declined by application by somewhat vague comments about "security" and not needing one because DBGp runs on a LAN.

As to the security aspect, they require authentication and encryption for new protocols, and of course DBGp isn't new. I would like to add an encryption layer to DBGp, but I can't require this right away, as that would mean no IDE can talk DBGp any more. Requiring authentication (i.

Truncated by Planet PHP, read more at the original (another 5031 bytes)

カテゴリー: php

Leaders Wanted

planet PHP - 2019-09-07(土) 02:55:00

In the best companies, everyone is a leader. Decisions are made by those best suited to make them, everyone feels trusted and respected, and a shared purpose provides unity and motivation.

I’ve been trying to be a better leader my entire career, and I still have much to learn. Nevertheless, some lessons I’ve learned along the way have stood the test of time, and I’d like to share them with you.

Mind your morale

Morale is a currency; spend it wisely.

One of the most important responsibilities of any leader is to manage the morale and energy of the team. If you’re a freelancer, self-awareness is key, because you must manage yourself, and tending to your own morale is critical to your success.

Managing morale doesn’t mean avoiding hard work. In my experience, providing an environment that lets people do their best work is what keeps morale high.

Decide who decides

Clearly defined roles and responsibilities help everyone. A leader’s job is to trust the right people to make the right decisions, and to provide the necessary context to do so.

When someone is a designated decision-maker, they are more likely to listen carefully to other views, because they don’t have to spend energy presenting or defending their own. Others will feel heard, because the decision-maker is actually listening. Everyone wins.

Choose words carefully

Language is important. The words we use shape our perspective and the perspectives of everyone we work with.

Make we a habit. They didn’t make a mistake; we made a mistake. The client doesn’t have a big opportunity; we have a big opportunity.

When you’re certain about something, say so, but also make it clear when you’re not. Expressing uncertainty doesn’t erode trust, but expressing certainty and being wrong does.

Set healthy boundaries

Communication is good, but be deliberate about it. The cost of real-time, always-on communication tools shouldn’t be overlooked, especially when used with clients. When possible, stick to email and scheduled meetings.

Avoid working outside of normal working hours, too. It’s more sustainable, and often more productive, to use a strict work schedule to help you and your team stay focused and driven. Don’t let the possibility of after-hours work excuse lacklustre performance during the day.

Make meetings count

Meetings are often unfairly maligned. It’s true that a poorly-organized meeting can be disruptive and wasteful, but a good meeting can be invaluable.

Every meeting needs a goal. Agendas are good, but goals are better. With a clear goal, it’s easy to intuit when the meeting is the least bit off-track, so you can correct course as you go. It’s also worth making clear if a meeting is meant to be divergent (new ideas welcome) or convergent (time to reach a consensus).

Make a habit of designating someone to take notes, and email the notes to everyone after the meeting. This will help you move more quickly, because no one will be worried about missing something. It also gives you a good excuse to exclude optional attendees; they can just read the notes. Small meetings without bystanders are more efficient.

Create your own rules

Some of the best lessons will come from your own experience.

A rule we adhere to on my team, for example, is to never estimate someone else’s work. This gives each person a sense of responsibility to the schedule and helps prevent unreasonable expectations.

Try to avoid treating any rule as dogma, however. ‘It depends’ is the only rule that is always dependable, so be willing to make an exception for a really good reason.

Stay humble

Leadership is a skill that requires study and practice, just like any other, and learning from one another is a great way to continue to improve. As peers, we share common threads, so the lessons we learn do as well.

I’m convinced that the most meaningful work is teamwork. Let’s learn together and work together to deliver on the web’s promise. Leaders wanted.

The original version of this article was commissioned for New Adventures magazine, January 2019.

カテゴリー: php

PHP Town Hall: Episode 68: Behind the Facade - 2019-09-06(金) 23:30:02

Matt Trask and Ben Edmunds are joined by Taylor Otwell to discuss what’s new with Laravel, the business side of things, and what it’s like organizing a huge conference.


Laravel Forge Vapor Ignition

カテゴリー: php

PHP on the road to the 7.4.0 release

planet PHP - 2019-09-06(金) 17:35:00

Version 7.4.0RC1 is released. It's now enter the stabilisation phase for the developers, and the test phase for the users.

RPM are available in the remi-php74 repository for Fedora  29 and Enterprise Linux  7 (RHEL, CentOS) and as Software Collection in the remi-safe repository (or remi for Fedora)


The repository provides development versions which are not suitable for production usage.

Also read: PHP 7.4 as Software Collection

Installation : read the Repository configuration and choose installation mode.

Replacement of default PHP by version 7.4 installation, module way (simplest way on Fedora and EL-8):

dnf module disable php dnf module install php:remi-7.4 dnf update

Replacement of default PHP by version 7.4 installation, repository way (simplest way on EL-7):

yum-config-manager --enable remi-php74 yum update php\*

Parallel installation of version 7.4 as Software Collection (x86_64 only, recommended for tests):

yum install php74

To be noticed :

  • EL7 rpm are build using RHEL-7.6
  • EL6 rpm are build using RHEL-6.10
  • lot of extensions are also available, see the PECL extension RPM status page
  • follow the comments on this page for update until final version.

Information, read:

Base packages (php)

Software Collections (php74)

カテゴリー: php

Interview with Junade Ali

planet PHP - 2019-09-06(金) 12:35:00
カテゴリー: php

Interview with Junade Ali

planet PHP - 2019-09-06(金) 11:05:00
カテゴリー: php

PHP: Hypertext Preprocessor: PHP 7.4.0RC1 Released! - 2019-09-06(金) 01:30:01

The PHP team is glad to announce the first release candidate of PHP 7.4: PHP 7.4.0RC1. This continues the PHP 7.4 release cycle, the rough outline of which is specified in the PHP Wiki. Please DO NOT use this version in production, it is an early test version. For source downloads of PHP 7.4.0RC1 pl...

カテゴリー: php

Derick Rethans: PHP Internals News: Episode 26: Making Symfony ready for PHP 7.4 - 2019-09-06(金) 00:00:02
PHP Internals News: Episode 26: Making Symfony ready for PHP 7.4 London, UK Thursday, September 5th 2019, 09:26 BST In this episode of "PHP Internals News" I chat with Nicolas Grekas (Twitter, GitHub, LinkedIn, Symfony Connect) about how th...
カテゴリー: php

510 Not Extended

planet PHP - 2019-09-06(金) 00:00:00

[RFC2774][2] is an experimental RFC, that introduces a mechanism to allow developers to extend the HTTP protocol with vendor-specific features in a safe namespaced way.

Around this time many new protocols and systems started to get built on top of HTTP, and the authors might have felt there was a need to do this in a namespaced way.

This is not unlike XML namespaces, where it’s possible for one standards organization to define a new format (for example ATOM), and other corporations wanting to add new properties, avoiding the possibility of collision if a second vendor also introduced a property with the same name.

As far as I know this extension to HTTP can be considered dead.

The 510 Not Extended statuscode could be used when a server requires that a client uses an ‘extended HTTP request’, but didn’t. When a server emits this response, it should also tell the client how to extend the request, but the specification doesn’t specify a format for this.

Because this error is a ‘client error’, it should probably have had a 4xx code, not a 5xx one.

I would not recommend for anyone to use this.

Should I use this?

No. RFC2774 is a very obscure extension to HTTP, and as far as I know has never really been picked up. If you feel you have a need for this, I believe there is likely to be a different way to extend HTTP. Perhaps via content negotiation, or just different kinds of messaging from client to server.

カテゴリー: php

PHP 7.4.0RC1 Released! - 2019-09-05(木) 17:39:13
カテゴリー: php

PHP 7.4.0RC1 Released!

planet PHP - 2019-09-05(木) 09:00:00
The PHP team is glad to announce the first release candidate of PHP 7.4: PHP 7.4.0RC1. This continues the PHP 7.4 release cycle, the rough outline of which is specified in the PHP Wiki. Please DO NOT use this version in production, it is an early test version. For source downloads of PHP 7.4.0RC1 please visit the download page. Please carefully test this version and report any issues found in the bug reporting system. For more information on the new features and other changes, you can read the NEWS file, or the UPGRADING file for a complete list of upgrading notes. These files can also be found in the release archive. The next release would be 7.4.0RC2, planned for September 19th. The signatures for the release can be found in the manifest or on the QA site. Thank you for helping us make PHP better.
カテゴリー: php

Akra's DevNotes: Receiving input into a Slim 4 application - 2019-09-05(木) 05:30:02

A Slim 4 (and Slim 3) application receives data from three places: Any query parameters on the URL (the key-value pairs after the ?) The HTTP message's body (usually for POST and PUT) messages Parameters in the URL (such as the 3 in Within the application, these are a...

カテゴリー: php

Interview with Junade Ali

planet PHP - 2019-09-05(木) 05:01:00
カテゴリー: php

Receiving input into a Slim 4 application

planet PHP - 2019-09-04(水) 19:00:00

A Slim 4 (and Slim 3) application receives data from three places:

  • Any query parameters on the URL (the key-value pairs after the ?)
  • The HTTP message's body (usually for POST and PUT) messages
  • Parameters in the URL (such as the 3 in

Within the application, these are available within the PSR-7 Request object.

Let's start with a simple Slim 4 application.

Firstly we require the Slim framework and a PSR-7 implementation:

$ composer require slim/slim slim/psr7

Now we write public/index.php:

<?php declare(strict_types=1); use Psr\Http\Message\ResponseInterface as Response; use Psr\Http\Message\ServerRequestInterface as Request; use Slim\Factory\AppFactory; require __DIR__ . '/../vendor/autoload.php'; $app = AppFactory::create(); $app->addRoutingMiddleware(); $app->addErrorMiddleware(true, true, true); $app->get('/', function (Request $request, Response $response, $args): Response { // our code for this handler goes here return $response; }); $app->run();

This is the standard minimal Slim 4 application, which will respond solely to the / URL (i.e. the home page of the website) and will return an empty response. See A first look at Slim 4 for more information.

We can run our website with:

$ php -S -t public/

If we navigate to https://localhost:8888 we'll see a blank page.

Query parameters

Query parameters are the key value pairs after the ? in the URL. For example in the ULR http://localhost:8888?name=Rob, we have a parameter name with the value Rob.

To access this in our Slim 4 handler, we use the Request's getQueryParams() method. This will return an array of all query parameter.

i.e. if we add:

// our code for this handler goes here $params = $request->getQueryParams() var_dump($params);

And then navigate to localhost:8888/?name=Rob&country=UK, we will see:

array (size=1) 'name' => string 'Rob' (length=3) 'country' => string 'UK' (length=2)

Note that the PSR-7 RequestInterface doesn't have a method to retrieve a single parameter, so if you just want a one parameter, the easiest way is to use the null coalescing operator (??) like this:

$name = $request->getQueryParameters()['name'] ?? '';

This will either set $name to the value of the name query parameter if it exists or set it to an empty string otherwise

Posted form data

For form data posted to the website from a browser, we can use the $request's getParsedBody() method. This will return an array of the posted data.

Firstly we set up a form:

$app->get('/', function (Request $request, Response $response, $args): Response { $html = <<<html <html> <form method="POST"> <label>Name: <input name="name"></label> <label>Country: <input name="country"></label> <input type="submit"> </form> </html> html; $response->getBody()->write($html); return $response; });

We also need a handler to receive the POSTed data:

$app->post('/', function (Request $request, Response $response, $args): Response { $data = $request->getParsedBody(); $html = var_export($data, true); $response->getBody()->write($html); return $response; });

If we fill out our form with the same name and country as before:

(html/CSS isn't really my forté!)

we'll get:

array ( 'name' => 'Rob', 'country' => 'UK', )

Again, the PSR-7 Request object doesn't have a method to retrieve a single parameter from POSTed data, but in my experience this is rarely a requirement anyway.

POSTed JSON or XML data

It's very common in web APIs to send data in XML or JSON format. Out of the box, PSR-7 implementations do not support these formats, you have to decode the Request object's getBody() yourself. As this is a common requirement, Slim 4 provides BodyParsingMiddleware to handle this task.

This is added using:


Truncated by Planet PHP, read more at the original (another 3313 bytes)

カテゴリー: php