PHP 8.4 released in November, and you and your team have no doubt been hard at work understanding the new features, deprecations, and changes that accompany this latest iteration of the language. This includes changes to non-POST HTTP verbs.
In this blog, I walk through the background of HTTP verbs in PHP, explaining why the HTTP verbs changes in PHP 8.4 matter. I then provide a guide for developers to reference when implementing these changes within their code.
PHP was developed with the web in mind and supported form handling from its earliest days. Originally in HTTP, there were essentially only two methods via which a browser could request a web page: via GET or POST. While HTML forms still only really support these two methods, JavaScript has the ability to send HTTP requests using any HTTP method, and a number of toolkits (e.g. HTMX) can even handle this seamlessly for developers.
A GET request passes form data via the URL's query string. This means that the form results can be bookmarked, repeated, and even cached. Because of this, GET requests are commonly only used for actions that are requesting state without altering state: searches, result sorting, result filtering, pagination, etc.
If you want to perform an action that might make changes within an application — e.g., processing a shopping cart, sending a support message, uploading an image, etc. — you will use the POST HTTP method. POST requests are considered non-idempotent, meaning they cannot be cached and should not be repeated, because they have side effects. Those effects might mean inserts, changes, or deletions in a database, filesystem operations, web requests, or something else.
In order to automate handling of form data, PHP provides several superglobal variables that it populates from the incoming request. $_GET is populated with URL query string arguments and can be populated from any request method. $_POST, however, is only populated from the body of POST requests made using the content type application/x-www-form-urlencoded, which might look something like this:
title=HTTP Verbs Changes in PHP 8.4&url=https://example.org/blog/php-8.4-http-verbs&author=Just Some Guy&tags[0]=php&tags[1]=http
PHP will take that and populate the $_POST superglobal such that it becomes the following:
<?php $_POST = [
'title' => 'HTTP Verbs Changes in PHP 8.4',
'url' => 'https://example.org/blog/php-8.4-http-verbs',
'author' => 'Just Some Guy',
'tags' => ['php', 'http'],
];
The fact that PHP does this behind the scenes for you is part of what makes PHP so easy to learn and get started with.
Further, it can also handle the content type multipart/form-data, which allows a browser to upload files in addition to provide form data. When it does so, it will populate an additional $_FILES superglobal, which provides information on the files uploaded; developers can then validate and pre-process those files before storing them in a permanent location.
There are a lot more HTTP methods than GET and POST, and developers for the web often will want to choose different methods to provide context to what they are attempting to do:
While browsers do not support these natively (yet!), many JavaScript frameworks and libraries do.
But there's a catch: PHP does not automatically handle these requests. In fact, you have to handle parsing of these entirely on your own, which can be hugely problematic when you also start handling file uploads as well as form data. (Never roll your own parsers!)
PHP 8.4 introduces the method request_parse_body():
title=HTTP Verbs Changes in PHP 8.4&url=https://example.org/blog/php-8.4-http-verbs&author=Just Some Guy&tags[0]=php&tags[1]=http
The
function parses the incoming request in the same way that it always has
for POST requests, but allows you to specify alternate variables to
store the form data and file uploads in (or overwrite the superglobals,
if you prefer). You can also alter the behavior of the parser via the $options argument, with more on that below.
A common pattern will likely be:
<?php $_POST = [
'title' => 'HTTP Verbs Changes in PHP 8.4',
'url' => 'https://example.org/blog/php-8.4-http-verbs',
'author' => 'Just Some Guy',
'tags' => ['php', 'http'],
];
(Though if you're using a framework, expect the framework to take care of that detail for you.)
That's literally the entirety of the feature. A simple function to provide turnkey behavior you're already familiar with as a PHP developer. It doesn't get much better than this!
Now that we've talked through the changes to HTTP verbs in PHP 8.4, let's take a look at a few examples for how you can use and apply these updates in your code.
Just like POST requests, request_parse_body() will only parse requests with the following content types:
In the case of application/x-www-form-urlencoded, the $_FILES-equivalent array (index 1 in the returned array) will be empty. If the content type is not supported, the function will throw an InvalidArgumentException.
PHP allows you to inspect the raw request content via the php://input stream. This is a buffered stream that can be (as of PHP 7.4) read multiple times. However, when receiving multipart/form-data content, PHP gets a bit destructive, for a very good reason: buffering files could lead to the file content being written to disk twice, leading to more memory, storage, and I/O usage.
As such, request_parse_body() MUST NOT be called twice, as it will destructively consume php://input.
The $options parameter to request_parse_body() allows you to alter its behavior at runtime, instead of relying on hard-coded php.ini configuration.
The above is the detailed content of HTTP Verbs Changes in PHP 8.4. For more information, please follow other related articles on the PHP Chinese website!
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
