it-swarm.com.de

HTTP POST Nutzlast im Chrome-Debugger nicht sichtbar?

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

Fehlerbeispiel

 No form data, No raw content .

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

 Some of them are able to work

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 
59
Mond Wan

In Chrome v61 und v62 gab es auf allen Plattformen einen Regressionsfehler, der zu diesem Verhalten führte, wenn die Antwort (unter anderem) eine 302 war. Dieser Fehler wurde in v63 stable behoben, das am 6. Dezember 2017 auf allen Desktop-Plattformen veröffentlicht wurde. 

Die automatischen Updates werden schrittweise durchgeführt. Wenn Sie jedoch auf "Hilfe"/"Über Google Chrome" gehen, wird das Update erzwungen, und Sie können eine Schaltfläche zum Neustarten aufrufen. Gelegentlich müssen Sie den gesamten Chrome-Prozess beenden und manuell neu starten, um das Update zu erhalten.

Der (jetzt geschlossene) Fehlerbericht ist hier . Die Freigabemitteilung ist hier .

Natürlich ist dies nicht die Ursache für die Ausgabe des ursprünglichen Posters im Jahr 2015, aber die Suche nach dem Problem führte mich hierher. Beachten Sie auch, dass dies nicht nur ein Problem mit OS X ist.

128
Leo Hendry

Wenn Ihre Anwendung einen 302-Statuscode und keine Nutzdaten in Chrome Devtools) zurückgibt, sind Sie möglicherweise trifft diesen Chrome Bug .

Wenn Sie sich in der Entwicklung befinden oder dies eine URL ist, die nichts kaputt macht, besteht eine schnelle, sehr praktische Problemumgehung darin, den serverseitigen Code so zu ändern, dass 200 gesendet werden, z. B. in PHP you könnte hinzufügen:

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

die sendet einen 200-Status-Code aus. Dies funktioniert um den "302-Fehler" - bis es behoben ist.

p.s. Laut @ leo-hendry hat Canary die Fehlerbehebung ab Dezember 2017, aber wenn Sie keinen weiteren Grund haben, Canary zu betreiben, lohnt es sich nicht, einen anderen Browser nebeneinander zu betreiben, wie es die Hauptversion tun sollte kommt bald raus.

16
Charlie Dalsass

Ich habe gerade bemerkt, dass Sie POST -Daten nicht sehen können, wenn Sie in den Filtern im Chrome-Debugger "Doc" (neben All, Xhr, Css, JS ...) auswählen. Wird angezeigt, wenn Sie "Alle" auswählen.

3
geert3

Wenn dies ein Fehler ist, verhält es sich möglicherweise auf Mac und Windows anders.

Der nachstehende Screenshot stammt von Chrome 63 unter Windows. Sie können den Request-Payload-Abschnitt wie erwartet sehen.

 Good Example

Hier ist das, was ich auf Chrome 65 Beta unter Mac sehe. Beachten Sie, dass der Abschnitt mit den Anforderungsnutzdaten fehlt.

 Bad example

Kann ich davon ausgehen, dass der Fehler nicht behoben ist oder gibt es noch etwas, das ich überprüfen sollte?

1
Chad Juliano

Ihr Code sieht in Ordnung aus. Haben Sie die Chrome-Konsole auf Fehler überprüft? Wenn Sie Zugriff auf den Server haben (und unter Linux davon ausgehen, dass es httpd ist), können Sie ein kleines CGI-Shell-Skript erstellen, um die Header und Daten an diesem Ende zu überprüfen:

#!/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
0
geert3

Ich habe wahrscheinlich das gleiche Problem mit der Chrome-Konsole (Chrome 69).

Weder die Formdata- noch die Payload-Registerkarte wird angezeigt ..__ In meinem Szenario POST füge ich ein Formular mit dem enctype "multipart/form-data" zu einem iframe hinzu (Senden einer Bilddatei über https an denselben Ursprung). Es funktioniert wie erwartet, aber ich weiß nicht, wie man die Daten in Chrome richtig debuggt, wenn sie überhaupt nicht angezeigt werden. Ich könnte die Daten in PHP ausgeben, aber das ist unnötig kompliziert und verpasst den Sinn der Konsole. Ich habe die vorgeschlagenen Lösungen oben durchgelesen, konnte dieses Problem jedoch nicht beseitigen. (Der Antwortcode ist 200 BTW und nicht 302).

 Formdata and payload missing

$_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
    )
)
0
Chris S.