php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #57709 HttpMessage::toMessageTypeObject() does not populate POST fields
Submitted: 2007-06-18 17:05 UTC Modified: 2007-08-30 07:30 UTC
From: pmjones@php.net Assigned: mike (profile)
Status: Closed Package: pecl_http (PECL)
PHP Version: 5.2.1 OS: Irrelevant
Private report: No CVE-ID: None
 [2007-06-18 17:05 UTC] pmjones@php.net
Description:
------------
Not sure if this is a bug, or if it's intended.  Given a POST request, if you do this ...

$message = HttpMessage::fromEnv(HttpMessage::TYPE_REQUEST);
$request = $message->toMessageTypeObject();
$data = $request->getPostFields();

... then $data comes back as null.  However, if you do this ...

$data = $request->getRawPostData();

... then $data comes back as the raw string.

Should not the toMessageTypeObject() method populate the POST fields in this case?

Thanks for any assistance.


Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2007-06-19 14:13 UTC] mike@php.net
This bug has been fixed in CVS.

In case this was a documentation problem, the fix will show up at the
end of next Sunday (CET) on pecl.php.net.

In case this was a pecl.php.net website problem, the change will show
up on the website in short time.
 
Thank you for the report, and for helping us make PECL better.

It will be decoded if REQUEST_METHOD==POST in future versions.

Thanks a lot.
 [2007-08-08 15:51 UTC] clay at killersoft dot com
Version 1.5.4 solves this issue for POSTs with Content-Type of application/x-www-form-urlencoded, but this still doesn't work for POSTs from forms with enctype="multipart/form-data".
 [2007-08-30 07:30 UTC] mike@php.net
Ugh, this is because PHP consumes all data at request startup and fills $_FILES etc. I wonder if it's really worth the hassle... reconstructing an artificial request body out of $_FILES ans $_POST.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Dec 13 10:01:28 2024 UTC