PHP Curl Post Request - not sending payload - php

Question

I'm trying to set up a proxy server to make a post request. Problem is when I make the request I am not seeing the payload.
One thing I notice is that curl seems to be adding an extra "boundary" to the content-type in the request.
Am I missing something?
The Code:
$contentType = $_SERVER["HTTP_CONTENT_TYPE"];
$post = http_build_query($_POST);
$ch = curl_init();
$header = array("Content-Type:" . $contentType,
"Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8",
"Accept-Encoding:gzip, deflate, br",
"Accept-Language:en-US,en;q=0.8",
"Connection:keep-alive",
"User-Agent:Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36",
"Cache-Control:max-age=0",
"Upgrade-Insecure-Requests:1",
"Origin:<url here>");
echo "<b>POST</b><br>" . var_dump($_POST) . "<br><br>";
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_POST, count($_POST));
curl_setopt($ch, CURLOPT_POSTFIELDS, $_POST);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, TRUE);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, false);
curl_setopt($ch, CURLINFO_HEADER_OUT, true);
curl_setopt($ch, CURLOPT_COOKIEFILE, "cookiejar.txt");
curl_setopt($ch, CURLOPT_HTTPHEADER, $header);
curl_setopt($ch, CURLOPT_HEADER, 1);
$result = curl_exec($ch);
$headerSent = curl_getinfo($ch, CURLINFO_HEADER_OUT );
echo "<b>Request Header</b><br>$headerSent<br><br>";
$header_size = curl_getinfo($ch, CURLINFO_HEADER_SIZE);
$header = substr($result, 0, $header_size);
$body = substr($result, $header_size);
echo "<b>Response Header</b><br>$header<br><br>";
echo "<b>Response Body</b><br>$body";
Response
$_POST = array(5) { ["formFields_Complaint_Type"]=> string(9) "1-GM2-226"
["formFields_Descriptor_1"]=> string(10) "1-GM3-3085"
["formFields_Descriptor_2"]=> string(9) "1-GM4-903"
["formFields_Date/Time_of_Occurrence"]=> string(0) "" ["_target1"]=> string(1) " " }
Request Header:
POST <relative address> HTTP/1.1 Host: <url>
Cookie:
JSESSIONID=mDMJZQdLV4bhvJQ6vPyQvxqHVTynGS3byBnYsTpjDvY1xBnB93R8!-759339305!-1867032216 Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding:gzip, deflate, br
Accept-Language:en-US,en;q=0.8
Connection:keep-alive
User-Agent:Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36
Cache-Control:max-age=0 Upgrade-Insecure-Requests:1
Origin: <url>
Content-Length: 633
Expect: 100-continue
Content-Type:multipart/form-data; boundary=----
WebKitFormBoundarybdBepqnmjSF86t50; boundary=------------------------
f8e2ad22b9bb626c

Answer 1

best guess: your (biggest, code-breaking, but not only) problem is that the target server supports only application/x-www-form-urlencoded-encoded POST requests, but your curl code converts both application/x-www-form-urlencoded-encoded requests, and multipart/form-data requests to multipart/form-data, regardless of what the client used. (this is because PHP transparently translates both of them to an equal native PHP array called $_POST)
this will use multipart/form-data encoding:
curl_setopt($ch, CURLOPT_POSTFIELDS, $_POST);
this will use application/x-www-form-urlencoded encoding:
curl_setopt($ch, CURLOPT_POSTFIELDS, http_build_query($_POST));
you must decide which encoding to use, based on $_SERVER["HTTP_CONTENT_TYPE"];
and if its neither of those (for example, if its application/json), you must add special code to handle each, and you should probably error out whenever $_SERVER["HTTP_CONTENT_TYPE"]; is not 1 of the types you have made a special case for (like raw $_POST for multipart, and http_build_query($_POST) x-www-form-urlencoded)
also you're not forwarding arbitrary http headers, you should probably add some code for that
and if you really need to support Upgrade-Insecure-Requests:1 header, you need to implement specific code to handle that at the proxy side (go read the http specs on the subject - https://www.w3.org/TR/upgrade-insecure-requests/ )
and you say to the target that you accept Accept-Encoding:gzip, deflate, br , but provide no code to decode any of them, so it will look like garbage binary data to the client if the target server decide to use any of them (curl can decode them for you though, using CURLOPT_ENCODING, if libcurl was compiled with gzip and deflate and br support. i've never seen a libcurl with br support, and i bet your curl doesn't have it. probably have gzip/deflate support compiled-in though)