php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Request #61439 POST and other methods input data handling
Submitted: 2012-03-19 17:36 UTC Modified: 2015-04-13 16:27 UTC
From: martin dot koranda at gmail dot com Assigned:
Status: Duplicate Package: *General Issues
PHP Version: 5.4.0 OS: *
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: martin dot koranda at gmail dot com
New email:
PHP Version: OS:

 

 [2012-03-19 17:36 UTC] martin dot koranda at gmail dot com 
Description:
------------
when sending multipart/form-data via a POST method, PHP internally parses all 
variables into $_POST and files into $_FILES. but the parsing is not done with any 
other method (PUT,PATCH,PROPFIND ..)

additionally, sending POST with multipart/form-data makes php://input unavailable.

so there is no universal parsing solution which covers all methods.

there should be a setting option (php.ini) where i can determine which particular 
methods i want the internal parser run for (eg.  "parse_input_methods = 
POST,PUT,PATCH")

and/or there should be an option for disabling that internal parser completely.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2012-03-20 09:01 UTC] mike@php.net 
I second that. Actually I've sitting an unfinished proposal in my Inbox' Drafts 
which addresses this issue.

BUT, I'm not thinking about php.ini, but SAPI code shouldn't care about the 
request method, but the request body's content type. And there should be an API 
to register content-type handlers.
 [2012-03-20 09:01 UTC] mike@php.net
-Operating System: windows +Operating System: *
 [2012-03-20 15:14 UTC] martin dot koranda at gmail dot com 
mike:   yes that's better, parse it regarding on the request content type. it 
should be also good if it could automatically parse json or xml input, but main is 
the multipart.
do you think you can push your proposal to some of the next builds?
 [2015-04-13 16:27 UTC] mike@php.net
-Status: Open +Status: Duplicate
 [2015-04-13 16:27 UTC] mike@php.net 
See bug #55815 and also https://pecl.php.net/package/json_post and https://pecl.php.net/package/apfd
 [2020-06-25 13:59 UTC] me at daz dot one 
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.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Thu Apr 18 23:01:27 2024 UTC