My Cup of PHP

PHP and Async requests with file based sessions

A few days ago, I wrote An Open Letter to PHP-FIG. Largely the feedback on it was positive, but not all. So I feel like I do have a few more things to say. What follows is a collection of followups to specific points of contention raised about my post. I'm going to ignore the politics and any non-technical discussion here.

I Don't Understand The Cache Proposal!!!

Two PHP developers fighting over which is faster echo with double quotes vs. echo with single quotes...

The title of the post is quite obvious. Apache2 + mod_php5 lost the so called “crown” for quite a while. The fist eye opener was a thing that got me pretty annoyed back in 2008. Dual-quad machine, 4 GiB of RAM, RAID 5 SAS @ 10k RPM – the server was looking pretty good, apparently. The only show stopper: Apache2 + mod_php5 that choked at 350 concurrent clients. What? No more free RAM? WTF? LAMP is not my cup of tea for obvious reasons. LEMP seems to be more appropriate while I ditched Apache from all the production servers.

PHP is a server-side scripting language designed for web development but also used as a general-purpose programming language. As of January 2013, PHP was installed on more than 240 million websites (39% of those sampled) and 2.1 million web servers. Originally created by Rasmus Lerdorf in 1994, the reference implementation of PHP (powered by the Zend Engine) is now produced by The PHP Group. While PHP originally stood for Personal Home Page, it now stands for PHP: Hypertext Preprocessor, which is a recursive acronym.

When developing compilers and interpreters, their source code and its testing procedure are demanded to comply with especially strict quality and reliability requirements. However, there are still some suspicious fragments found in the PHP interpreter's source code.

So if you really wanted to revamp this ancient API you probably want to do away with $_POST/$_GET/$_REQUEST/$_FILES superglobals altogether and really think about this problem for a second.

PHP deals with HTTP directly in many ways. It reads, parses, and sometimes even generates HTTP headers/bodies in key areas. Like when session_start() is called, PHP looks for an HTTP cookie header and seeks out the session_name() cookie then matches it against the available session storage data to either populate or initialize the $_SESSION superglobal.

So why is the HTTP request METHOD important in distinguishing which super global variable we use?

It isn't!

Things php populates $_POST are merely form url encoded parts of the HTTP request body. $_GET is populated from the request header's path string after parsing the query parameters (if any). So realistically anyone requesting support for $_PUT actually doesn't understand how HTTP works or how PHP deals with HTTP requests and how these superglobals are being populated.

The real problem here is that PHP doesn't parse the request body and populate it in $_POST unless the body is properly url encoded according the HTTP spec. Instead, you have to deal with the php://input stream directly and parse it yourself.

The PUT HTTP verb is intended to act upon the destination URI directly as per the enclosed entity, according to rfc2616. Yet, people seem to understand RESTful less than they regurgitate the word.

The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. The URI in a POST request identifies the resource that will handle the enclosed entity. That resource might be a data-accepting process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request identifies the entity enclosed with the request -- the user agent knows what URI is intended and the server MUST NOT attempt to apply the request to some other resource.

So let's forget about HTTP verbs for a second and deal with the HTTP request through some sane (non-backwards-compatible) interface.

First, make PhpRequest a new extensible interface, expose it to userland, and allow the user to override it's implementation with user-implemented classes. Second, stop making the request parsing and content buffer flushing decisions at the RINIT stage. Let's just buffer and delegate to the runtime!