HTTP POST Nutzlast im Chrome-Debugger nicht sichtbar?

Ich habe das und das ausgecheckt. Mein Debugger sieht jedoch wie folgt aus.

Fehlerbeispiel

  .

Keine Formulardaten, kein Rohinhalt

Rohes Beispiel (* Obwohl der Pfad sich von der Bildschirmaufnahme unterscheidet, können beide keine Nachbearbeitungsdaten lesen.)

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

HINWEIS: (6)

Erfolgreiches Beispiel

Unterschiede zwischen ihnen, die ich entdeckt habe (durch Differenzierung des Kopfzeileninhalts) 

Rohes Beispiel (* Obwohl der Pfad sich von der Bildschirmaufnahme unterscheidet, können beide keine Nachbearbeitungsdaten lesen.)

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

HINWEIS: (6)

Header Unterschied zwischen zwei Beispielen

• Erfolgreiche Anwendung verwendet Jquery-Bindung , während Fehler eine Verwendung von HTTPS von nodejs + browserify verwendet. Ich finde jedoch immer noch einen Weg, um zu überprüfen, ob dies ein Problem ist oder nicht (nicht getestet).

• Fehlender X-Requested-With: XMLHttpRequest. Das Hinzufügen dieses Headers zur Anfrage behebt dieses Problem jedoch nicht (getestet).

• Großbuchstabe vs Kopfzeile für kleinere Buchstaben (

  • content-type und Content-type. Dieser Unterschied ist jedoch nicht die Ursache für mein Problem, wie es in Geige hier (getestet) versucht wurde.

  • Accept vs accept (nicht getestet)

HINWEIS: (5) (7)

Trotzdem bin ich nicht sicher, warum die erste c in content-type in Kleinbuchstaben ist.

ANMERKUNG 1)

Was ich versucht habe

Ich habe Firefox mit Firebug ausprobiert. Es kann meine Nutzlast anzeigen. Es kann jedoch keine Antwort vom Server analysieren: '(

Da der Webserver im HTTPS-Protokoll läuft, kann ich keine Pakete per Wireshark erfassen. Irgendwelche Vorschläge zum Debuggen von POST -Anfragen? Vielen Dank.

Verbindung zu einem Gist zum Debuggen von HTTP (s) -Anfragen über die Befehlszeile. NOTIZ 3)

Wrapper, den ich verwende

Ich habe diese Methode von nodejs mit einem Versprechen aufgerufen. Unten ist ein Ausschnitt einer Option, die ich verwendet habe.

/**
 * 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,
    };
};

Vollständige Quelle hier

ANMERKUNG 2)

Aktualisieren

• (1) Ich habe bestätigt, dass der Buchstabe c den Chrom-Debugger nicht beeinflusst. Hier ist die Geige . Ich habe versucht, dieselbe Anfrage mit XMLHttpRequest und dem Buchstaben c nachzuahmen. Ich kann immer noch Formulardaten im Debugger prüfen.
• (2) Link zum vollständigen Quellcode
• (3) Link zu einem Gist von mir über Skripts zum Testen der HTTP (s) -Anforderung
• (4) Formatieren Sie die Frage zur besseren Lesbarkeit
• (5) Beispiele verwenden nach der Codeüberprüfung nicht dieselbe Bindung
• (6) Fügen Sie ein Beispiel für ein Rohkopf hinzu
• (7) Fügen Sie eine Vergleichssitzung hinzu