|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
[2013-05-29 07:54 UTC] cataphract@php.net
[2014-11-19 12:29 UTC] mike@php.net
-Status: Open
+Status: Closed
-Assigned To:
+Assigned To: mike
[2014-11-19 12:29 UTC] mike@php.net
|
|||||||||||||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Sat Oct 25 19:00:01 2025 UTC |
Description: ------------ When a POST have an unknwon Content-Type, the php_default_post_reader store the body of the request three times : * In SG(request_info).post_data * In SET_VAR_STRINGL("HTTP_RAW_POST_DATA", ... * In SG(request_info).raw_post_data So, getting a 500Mb request body result in a 1.5Gb memory usage, easily triggering a "memory limit exhausted" error. Known content types are found in main/php_content_types.c and are "application/x-www-form-urlencoded" and "multipart/form-data", so this case is easily triggered. This fact seems well known as we can read in main/php_content_types.c:59 : /* for php://input stream: some post handlers modify the content of request_info.post_data so for now we need a copy for the php://input stream in the long run post handlers should be changed to not touch request_info.post_data for memory preservation reasons */ Solving this comment only fix 1/2 of the bug, keeping the body stored in two different locations, but it's a first step. I only open this ticket to track the history of this issue, I do not really need it to be fixed.