You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Here, $_POST['user'] will simply return the original value as decoding is not needed: [email protected]. However, http_build_query will encode the @ to read %40. And the original Content-Length header will not be increased to make up for the two extra characters. Hence, the remote server may get a truncated body.
I'm not using PHP a lot, but I'd be tempted to avoid any parsing that $_POST does, and always use php://input. However:
php://input is not available with enctype="multipart/form-data"
So maybe something like the following would be better?
It seems that
$_POST
andhttp_build_query
are not symmetrical. Currently,$_POST
is tried first when reading the original POST request:And if
$_POST
gets some content above, thenhttp_build_query
is used when passing the request to the remote server:Note that
$_POST
percent decodes if needed, buthttp_build_query
percent encodes whenever possible.For example, consider
Content-Type: application/x-www-form-urlencoded
with a POST body including an@
that (erroneously) is not percent-encoded:Here,
$_POST['user']
will simply return the original value as decoding is not needed:[email protected]
. However,http_build_query
will encode the@
to read%40
. And the originalContent-Length
header will not be increased to make up for the two extra characters. Hence, the remote server may get a truncated body.I'm not using PHP a lot, but I'd be tempted to avoid any parsing that
$_POST
does, and always usephp://input
. However:So maybe something like the following would be better?
(This works for me, but I have not tested with
enctype="multipart/form-data"
.)The text was updated successfully, but these errors were encountered: