> 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.