Req #55815 [Com]: PUT request data should be parsed just like POST

Edit report at https://bugs.php.net/bug.php?id=55815&edit=1 ID: 55815 Comment by: me at daz dot one Reported by: catch dot dave at gmail dot com Summary: PUT request data should be parsed just like POST Status: Suspended Type: Feature/Change Request Package: Streams related Operating System: All PHP Version: 5.4.0beta1 Block user comment: N Private report: N New Comment: I've been trying to figure out how to work with this issue without having to break RESTful convention and boy howdie, what a rabbit hole, let me tell you. I'm adding this anywhere I can find in the hope that it will help somebody out in the future. I've just lost a day of development firstly figuring out that this was an issue, then figuring out where the issue lay. After trawling through a good few RFCs for php core, the core development team seem somewhat resistant to implementing anything to do with modernising the handling of HTTP requests. The issue was first reported in 2011, it doesn't look any closer to having a native solution. That said, I managed to find a PECL extension called apfd (always populate form data). I'm not really very familiar with pecl, and couldn't seem to get it working using pear. but I'm using CentOS and Remi PHP which has a yum package. I ran: yum install php-pecl-apfd and it literally fixed the issue straight away (well I had to restart my docker containers but that was a given). I believe there are other packages in various flavours of linux and I'm sure anybody with more knowledge of pear/pecl/general php extensions could get it running on windows or mac with no issue. If you're looking for a clean fix for this issue, I'd personally advise taking a look. Previous Comments: ------------------------------------------------------------------------ [2020-06-24 14:29:41] me at daz dot one I know this has been said MANY times but I can't believe this is still not implemented. I get that it may not have been so essential in 2011 but in 2020 we now live in an age of REST APIs. Having to break RESTful convention due to this feature not being implemented is literally crazy. Is there anything I (or anybody else that needs this) can do to speed up getting it implemented? Thanks. ------------------------------------------------------------------------ [2019-07-06 00:01:49] requinix@php.net This needs to go through the RFC process. https://wiki.php.net/rfc/howto ------------------------------------------------------------------------ [2019-07-05 22:17:11] jasny@php.net How ca, this be solved? ---- Change the type of ini setting enable_post_data_reading to a string. This setting takes a comma-separated list with methods. E.g. "POST,PUT,PATCH". For BC also allow a boolean: true is "POST" and false is "". --- This will likely need to be proposed as RFC rather than a simple patch. ------------------------------------------------------------------------ [2019-01-19 15:50:04] arkemlar at gmail dot com The but exising over 8 years! Really, for me it sounds like: - Me: Hey PHP, I want to implement nice restful API - PHP: OK ... over time ... - Me: What? I cant use PUT to modify my entity? WTF dude? - Reqeust parsing for PUT is not implemented - Why? - Because maintainers __believe__ it should not be done for PUT - This literally means: go and f**k urself man becasue now I forced to broke my perfectly designed API by using POST whilest it must be PUT. In age of RESTful API we cant simply use PUT, perfect! ------------------------------------------------------------------------ [2018-10-05 08:23:17] a at anze dot com Was there any development to allow multipart/form-data on PATCH, PUT, DELETE.. type of requests? PHP is not suitable for RESTful API development not having this supported. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=55815 -- Edit this bug report at https://bugs.php.net/bug.php?id=55815&edit=1