HTTP POST payload not visible in Chrome debugger?

I have checked out this and that. However, my debugger looks like below.

Failure example

.

No form data, No raw content

Raw example (* Although path is different from the screen capture, both of them are unable to read post data)

POST https://192.168.0.7/cgi-bin/icul/;stok=554652ca111799826a1fbdafba9d3ac1/remote_command HTTP/1.1
Host: 192.168.0.7
Connection: keep-alive
Content-Length: 419
accept: application/json, text/javascript, */*; q=0.01
Origin: https://192.168.0.7
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.86 Safari/537.36
content-type: application/x-www-form-urlencoded; charset=UTF-8
Referer: https://192.168.0.7/cgi-bin/icul/;stok=554652ca111799826a1fbdafba9d3ac1/smartmomentl/access-point/network
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.8,zh-TW;q=0.6,zh;q=0.4
Cookie: sysauth=f15eff5e9ebb8f152e163f8bc00505c6

command=import&args=%7B%22--json%22%3Atrue%2C%22--force%22%3Atrue%2C%22--mocks%22%3A%22%7B%5C%22DEL%5C%22%3A%7B%7D%2C%5C%22SET%5C%22%3A%7B%5C%22dhcp%5C%22%3A%7B%5C%22lan%5C%22%3A%7B%5C%22.section%5C%22%3A%5C%22dhcp%5C%22%2C%5C%22interface%5C%22%3A%5C%22lan%5C%22%2C%5C%22ignore%5C%22%3A%5C%220%5C%22%2C%5C%22leasetime%5C%22%3A%5C%2212h%5C%22%2C%5C%22range%5C%22%3A%5C%22172.16.0.100-172.16.0.200%5C%22%7D%7D%7D%7D%22%7D

HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Status: 200 OK
Content-Type: text/html; charset=utf-8
Cache-Control: no-cache
Expires: 0
Transfer-Encoding: chunked
Date: Thu, 01 Jan 1970 00:09:27 GMT
Server: lighttpd/1.4.30

31
{ "ctx": "No such command", "exitStatus": false }
0

NOTE: (6)

Successful example

Differences between them I have spotted (by differentiating header contents)

Raw example (* Although path is different from the screen capture, both of them are unable to read post data)

POST https://192.168.0.7/cgi-bin/icul/;stok=92dea2b939b9fceb44ac84ac859de7f4/;stok=92dea2b939b9fceb44ac84ac859de7f4/remote_command HTTP/1.1
Host: 192.168.0.7
Connection: keep-alive
Content-Length: 53
Accept: application/json, text/javascript, */*; q=0.01
Origin: https://192.168.0.7
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.86 Safari/537.36
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Referer: https://192.168.0.7/cgi-bin/icul/;stok=92dea2b939b9fceb44ac84ac859de7f4/remote_command/command_reboot
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.8,zh-TW;q=0.6,zh;q=0.4
Cookie: sysauth=683308794904e0bedaaead33acb15c7e

command=command_reboot&args=%7B%22--json%22%3Atrue%7D

HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Status: 200 OK
Content-Type: text/html; charset=utf-8
Cache-Control: no-cache
Expires: 0
Transfer-Encoding: chunked
Date: Thu, 01 Jan 1970 00:02:46 GMT
Server: lighttpd/1.4.30

34
{ "ctx": "\u0022success\u0022", "exitStatus": true }
0

NOTE: (6)

Header Difference between 2 examples

• Successful one is using Jquery binding while failure one using HTTPS from nodejs + browserify. However, I am still finding a way to check whether this is a problem or not (Not tested)

• Missing X-Requested-With: XMLHttpRequest. However, adding this header back to the request does not fix this problem (Tested)

• Capital header vs Smaller letter header field (

  • content-type and Content-type. However this difference is not the root cause for my problem as tried in fiddle here (Tested)

  • Accept vs accept (Not tested)

NOTE: (5) (7)

Still, I am not sure why the first c in content-type is in small letter case.

NOTE: (1)

What I have tried

I have tried on Firefox with firebug. It is able to show my payload. However, it cannot parse response from the server :'(

Since the web server is running in HTTPS protocol, I cannot capture packets by wireshark. Any suggestion for debugging POST requests? Thanks.

Link to a gist about debugging HTTP(s) request via command line. NOTE: (3)

Wrapper I am using

I have wrap this method from nodejs with a promise calls. Below is a snippet show an option I have used.

/**
 * Wraps HTTPS module from nodejs with Promise
 * @module common/http_request
 */

var createRequestSetting = function (host, path, data, cookies) {
    return {
        method: 'POST',
        port:443,
        host: host,
        path: path,
        headers: {
            Accept: 'application/json, text/javascript, */*; q=0.01',
            'Content-Type':
                'application/x-www-form-urlencoded; charset=UTF-8',
            'Content-Length': Buffer.byteLength(data),
            'Cookie': cookies,
        },
        rejectUnauthorized: false,
    };
};

Full source here

NOTE: (2)

Update

• (1) I have verified the letter c does not affect chrome debugger. Here is the fiddle. I have tried to mimic same request with XMLHttpRequest with letter c. I can still check form data in the debugger.
• (2) Link to the full source code
• (3) Link to a gist from me about scripts to test HTTP(s) request
• (4) Reformat the question for readability
• (5) Examples are not using the same binding after code reviewing
• (6) Add raw header example
• (7) Add a comparison session

There was a regression bug in Chrome v61 and v62 across all platforms that caused this behaviour when the response is (amongst others) a 302. This is fixed in v63 stable which was released to all desktop platforms on 6th December 2017.

Automatic updates are phased, but going to "Help" / "About Google Chrome" will force it download the update and give you a button to restart. Occasionally it is necessary to kill all Chrome process and restart it manually to get the update.

The (now closed) bug report is here. The release announcement is here.

Clearly this is not the cause of the original poster's issue back in 2015, but searches for the issue led me here. Also note this is not just an OS X issue.

If your application returns a 302 status code, and no payload data in Chrome Devtools, you may be hitting this Chrome bug.

If you are in development or this is a URL which won't break anything, a quick, very practical, workaround is to modify your server side code to send a 200, for example in PHP you might add:

die("premature exit - send a 200");

which sends out a 200 status code. This works around the "302 bug" -- until it is fixed.

p.s. Per @leo-hendry below, Canary does have the fix as of Dec 2017, but if you don't have another reason to run Canary, running another browser side-by-side won't be worth it, as the mainline release should be coming out soon.

If this is a bug it may be behaving differently on Mac vs Windows.

The screenshot below is from Chrome 63 on Windows. You can see the request payload section as expected.

Here is what I see on Chrome 65 Beta running on Mac. Notice the request payload section is missing.

Am I correct to assume that the bug is not fixed or is there something else I should be checking?

I just noticed that you cannot see POST data if you select "Doc" from the filters in Chrome debugger (next to All, Xhr, Css, JS...). It does show if you select "All".

I probably got the same problem with the Chrome console (Chrome 69)

Neither the formdata nor the payload tab is showing. In my scenario I POST a form with enctype "multipart/form-data" to an iframe (submitting an image file over https to the same origin). It works as expected but I don't know how to debug the data in chrome properly when it doesn't show up at all. I could dump the data in PHP but that's unnecessary complicated and totally missing the point of using the console. I've read through the suggested solutions above but I didn't manage to get rid of this problem. (The response code is 200 btw, not 302).

$_POST = Array
(
    [xajax] => 1
    [app] => products
    [cmd] => upload
    [cat] => 575
)

$_FILES = Array
(
    [upfile] => Array
    (
        [name] => Aufkleber_Trollface.jpg
        [type] => image/jpeg
        [tmp_name] => /tmp/phpHwYkKD
        [error] => 0
        [size] => 25692
    )
)

Your code looks ok. Have you checked the Chrome console for errors? If you have access to the server (and assuming it is httpd on Linux) you could make a small CGI shell script to inspect the headers and data at that end:

#!/bin/bash

echo "Content-type: text/plain"
echo ""    
echo "Hello World. These are my environment variables:"
/usr/bin/env
if [ "$REQUEST_METHOD" = "POST" ]; then
    if [ "$CONTENT_LENGTH" -gt 0 ]; then
        echo "And this is my POST data:"
        /bin/cat
    fi
fi
exit 0

I had another issue, when as well my POST parameters somewhere missed, even in back-end and Chrome Headers, via very simple mistake in code.

I simply wrongly declared params object, as normal array:

var params = [];

Instead of:

var params = {};

And then assigned to it params, in result of what, I got no error, but it didn't worked:

params['param1'] = 'param1';
params['param2'] = 'param2';

$.post(url, params, function(data) {... 

In this way, data was not sent or received in back-end, same as not shown because not sent in debugger. It might save for someone hour or few sometimes.

Sometime if your form set enctype="multipart/form-data", then Chrome will not catch the request payload.

<form action="" method="POST" enctype="multipart/form-data">
</form>

REF

I have faced the same issue in Chrome Version 101.0.4951.67 (Official Build) (64-bit).

I did not use formData for some time, meanwhile, Chrome has been updated

FormData has been moved to separate tab Payload

Although this is not the answer of original question, my alternative is replacing the original implementation with the combo of form-data, es6-promise and isomorphic-fetch

All packages are able to download from npm.

It works charmly.