Re: Parsing PUT data
| From: | Daniel Lowrey | Date: | Tue, 24 Sep 2013 14:59:19 +0000 |
| Subject: | Re: Parsing PUT data | ||
| Groups: | php.internals | ||
| Request: | Send a blank email to internals+get-69318@lists.php.net to get a copy of this message | ||
> In short, in order to provide a proper REST service that supports
multipart
> form data, we need someway to parse data sent via PUT (data is available
> via php://input, but it needs to be parsed).
Multipart entity parsing is fairly straightforward. You could easily write
a parser in userland to accomplish the same thing. Unless you're doing a
very high volume of CRUD via PUT the performance hit of doing this in
userland should be negligible.
That said, I think exposing a function to do this could be a useful
addition, and since PHP already has code to parse these entities for POST
requests it shouldn't be too much work to expose that via something like a
new mime_multipart_parse() function. It's not really a priority for me, but
you can probably find someone to work on this for you if you're not a C
person.
The bigger issue here is that the superglobals are a leaky abstraction. Any
HTTP request method is allowed to have an entity body, so should we also
create $_PATCH and $_PUT and $_ZANZIBAR to handle less-frequently used
request methods? Where does it stop? This is the problem I see with all the
requests to support for PUT similarly to POST. PHP web SAPIs support 95% of
the HTTP use-cases people have, but the abstractions break down after that
and continuously bolting on support for individual scenarios beyond that
would be a mistake IMO.