|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #41191 Request for method to always retrieve POST body
Submitted: 2007-04-25 20:12 UTC Modified: 2012-02-07 16:05 UTC
Avg. Score:4.0 ± 1.0
Reproduced:4 of 4 (100.0%)
Same Version:2 (50.0%)
Same OS:0 (0.0%)
From: jfrim at idirect dot com Assigned: rasmus (profile)
Status: Closed Package: HTTP related
PHP Version: 5.2.1 OS: Win98
Private report: No CVE-ID: None
 [2007-04-25 20:12 UTC] jfrim at idirect dot com
Currently there exists no way in PHP to retrieve the POST body when a form is sent using multipart/form-data.  This is a problem for implementing protocols like HTTP digest authentication, which require the server to calculate a hash of the received POST body.

If making the POST body available on the php://input stream AT ALL TIMES regardless of the encoding type is impractical (possibly due to memory requirements when the POST body is very large), an alternative would be to stream the POST body, unaltered, directly to a temporary file.  (Similar to the way files uploaded with HTML forms are streamed to temporary files referenced in the $_FILES[] superglobal.)

This would allow authors to fully implement HTTP digest authentication in their scripts, and open up any other other possible situations where one might require an exact bit-accurate copy of the POST body.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2011-01-18 11:01 UTC] novikov at doroga dot tv
When the Java MIDP client sends wrong multipart/form-data message because of wrong Java implementation, I don't have a chance to fix the problem on the server side using PHP, just because I don't have any way to get a raw POST data.
 [2012-02-07 09:02 UTC] peter dot e dot lind at gmail dot com
This is still quite a bother:
When you send a POST request of type multipart/form-data, the POST data is parsed 
no matter what and you have no chance to check the request body. If the POST 
request is invalid somehow (for instance, if the boundary is set wrong) the 
parser throws away the entire request body leaving you in the dark as to why 
there's no data coming through. Essentially, you are left with "The request is 
invalid somehow, but I have no clue as to why" - and if you cannot reproduce the 
error yourself, you're completely screwed.
 [2012-02-07 09:10 UTC] jfrim at idirect dot com
-Package: Feature/Change Request +Package: HTTP related
 [2012-02-07 09:10 UTC] jfrim at idirect dot com

Almost 5 years later, and this still hasn't been resolved!??

Normally I'd be civil about this, but really, Really, REALLY, what's going on in the PHP development world?  This is pathetic.
 [2012-02-07 16:05 UTC]
-Status: Open +Status: Closed -Assigned To: +Assigned To: rasmus
 [2012-02-07 16:05 UTC]
This was actually addressed in PHP 5.4 with the "enable_post_data_reading" ini 
PHP Copyright © 2001-2020 The PHP Group
All rights reserved.
Last updated: Tue Dec 01 03:01:24 2020 UTC