According to php manual nor php://input neither $HTTP_RAW_POST_DATA work with multipart/form-data POST-requests.

"php://input allows you to read raw POST data. It is a less memory intensive alternative to $HTTP_RAW_POST_DATA and does not need any special php.ini directives. php://input is not available with enctype="multipart/form-data"."

How can I get raw data for multipart/form-data forms?

Comments

If it is for the sake of counting bytes, can't you combine the count of $HTTP_RAW_POST_DATA bytes with the byte count of any $_FILES ?

Written by karim79

Accepted Answer

Direct answer: you can not do that. PHP insists on parsing it itself, whenever it sees the multipart/form-data Content-Type. The raw data will not be available to you. Sadly. But you can hack around it.

I hit a similar problem, a partner was sending incorrectly formatted data as multipart/form-data, PHP could not parse it and was not giving it out so I could parse it myself.

The solution? I added this to my apache conf:

<Location "/backend/XXX.php">
    SetEnvIf Content-Type ^(multipart/form-data)(.*) NEW_CONTENT_TYPE=multipart/form-data-alternate$2 OLD_CONTENT_TYPE=$1$2
    RequestHeader set Content-Type %{NEW_CONTENT_TYPE}e env=NEW_CONTENT_TYPE
</Location>

This will change the Content-Type of incoming request to XXX.php from multipart/form-data to multipart/form-data-alternate, which is enough to block PHP from trying to parse it

After this you can finally read the whole raw data from php://input and parse it yourself.

It is ugly, but I have not found a better or in fact any other solution - short of asking the partner to fix their side.

NB! When you do what I described here, $_FILES will be empty.

Written by Anti Veeranna
This page was build to provide you fast access to the question and the direct accepted answer.
The content is written by members of the stackoverflow.com community.
It is licensed under cc-wiki