A discussion has started up on Reddit.com about the request for a "$_PUT" superglobal to match the already existing "$_POST" and "$_GET" (as is mentioned in this bug).

Data that is posted to PHP via the PUT method is not parsed at all and is not available to PHP. This is particularly problematic for data sent encoded as 'multipart/form-data'. [...] This is something that would help every RESTful interface that people are trying to do with PHP. There are many people who have these problems and have to implement (usually incomplete and/or buggy) PHP solutions.

In the Reddit post there's a mixed set of opinions - some say that things work well enough as is (content pulled from the raw stream) and others say that adding something like this makes the HTTP support more complete and functional.

PHPMaster.com is back with another introductory tutorial for those new to the PHP language. It's a look at one of the most commonly used (sometimes badly) features of the language - superglobal variables.

Superglobals are specially-defined array variables in PHP that make it easy for you to get information about a request or its context. They are called superglobal because they are always accessible, regardless of the scope - that is, you can access them from any function, class or file without having to do anything special. The superglobal variables are: $GLOBALS, $_SERVER, $_GET, $_POST, $_FILES, $_COOKIE, $_SESSION, $_REQUEST and $_ENV. And while you can learn more about each by reading the PHP documentation, I'd like to show you the ones I think you're likely use the most.

He goes through some of the major ones and explains what kind of situations they can be used in and what data would be inside - $_POST, $_GET, $_SESSION and $_SERVER.

In this new post to the php|architect blog Matt Butcher offers a security tip for all PHP developers out there - never use $_GET again.

You don't need to use $_GET or $_POST anymore. In fact, you probably shouldn't use $_GET and $_POST anymore. Since PHP 5.2, there is a new and better way to safely retrieve user-submitted data. [...] Rather than accessing the $_GET and $_POST superglobals directly, you can make use of PHP functions like filter_input() and filter_input_array().

He gives a code example of it in use and talks about the two things these functions do to help keep you safe - validate the data for correct match on criteria and sanitizing the value to ensure the return value is only what's requested. You can find more about these filter functions in the Filters section of the PHP manual.

DevShed has posted the last article in their series on filtering input (from whatever source) in your PHP application. This time the focus is on cleaning up the GET and POST superglobals.

The [filter] library is also capable of cleaning up strings in arrays, as well in data coming from GET and POST requests and cookies. Therefore, this final article of the series will demonstrate how to do this with a few understandable examples, in this manner concluding this quick introduction to working with the PHP 5 filter library.

They show how to use each of the constants referring to these superglobals (INPUT_GET, INPUT_POST, INPUT_REQUEST, etc) to run through each of the values and check them against another filter.

Revisiting an earlier post dealing with superglobals and classes, Brandon Savage looks at an example of why its still a bad idea.

I asserted at the time that superglobals inside of a class violated some basic rules on what a class was supposed to do. Today, I am revisiting that discussion. The placement of superglobals inside a class creates an impossible situation for code reuse. [...] Ehat happens when we want to move this [code] to another site? Unless we leave our form fields named [the same] we'll have to modify the original code.

His alternative - a much better refactoring - lets the verifyCredentials method take in the username and password and has the calling script define where those come from, either from a local or global location.

PHPBuilder.com has the next articles in their "ABCs of PHP" series posted today, a look at variables - what they are and how they're used.

To many beginners the subject of variables is usually pretty scary, and often a reasonably difficult concept to grasp, the reason for this however is usually because most modern languages require some kind of indication as to what type of data a variable will hold, this in turn often confuses beginners because they don't know what type of data relates to what kind of type.

They describe variables (using sample assignments like strings and numbers) and talk some about scope and how it affects their visibility. There's also a brief mention of the superglobals there close to the end.

Some of you might have heard about the hacking of the phpBB.com website earlier this week. Well, Stefan Esser has posted a bit more about the vulnerability in the PHPList software that lead to the problem.

A few days ago phpbb.com was hacked through a super-globals-overwrite vulnerability in PHPList that was used by an attacker for a local file inclusion exploit. Details about the whole attack, written down by someone who claims to be the attacker, can be read here.

Stefan talks about the superglobal problem PHPList had - allowing the superglobal information to overwrite the variables inside the script without so much as a check. Example code shows how it was possible for the attacker to provide their own configuration file value to be opened via a stream wrapper.

On the SitePoint PHP Blog today Troels Knak-Nielsen takes a deeper look at two of the superglobals a lot of PHP developers take for granted - $_GET and $_POST.

When a PHP script is invoked by a web server, it is as the result of a HTTP request. A HTTP request has a target URI and that URI consists of different parts. One of these parts is the query. As the PHP process starts up, the query gets parsed into an associative array. And for some reason, somebody decided on the unfortunate $_GET, because it's what you use for GET requests - right? Wrong!

He points out that all HTTP requests, regardless if they're GET or POST will have that GET information (not necessarily in $_GET, though). He also mentions another commonly used (and sometimes abused) superglobal - $_FILES. His biggest gripe, though, is that the naming of the variables confuses the developer as to the true content of the HTTP request.

And I won't even comment on the nastiness of $_REQUEST.

The PHPBuilder.com site has a quick new tutorial showing how to upload images to your server via a PHP script (including some error checking).

One of the most frequently asked questions about PHP is "how can I use PHP to upload an image". In this article we'll discuss the details of how you can do just that!

Their script is done in three steps - an HTML form to accept the input, the PHP script to handle the upload (working with the $_FILES superglobal) and another HTML page to let the user know their upload was a success. When the file is uploaded, they check for a few things: the internal error PHP could throw, ensuring that the uploaded file exists and checking to ensure that the file is an image. Only then is it moved over to the true uploads directory to be stored.

In a new post to his blog, Brandon Savage makes a suggestion that could help in maintenance and debugging down the road - keep those superglobals out of your classes.

Let's ignore the security implications of the above code for just a moment, and focus on just the use of the superglobal. By using the $_POST superglobal array, we're effectively doing two things [in the example code]: relying on the field names and limiting code reuse.

He shows how to refactor the example into something a bit more reusable by changing the method call to pass in the given username and password instead of looking to the global for it. He does note, however, that there are some more correct uses for those superglobals:

There are some legitimate uses of superglobals in classes. One example is the use of the $_SESSION superglobal, which is often used for things like a user object. But I urge you to do so sparingly, when appropriate, rather than relying heavily on superglobals which are subject to change and may not give you the data you expect.