Ich habe dies und das überprüft . Mein Debugger sieht jedoch wie folgt aus.

Fehlerbeispiel

.

Keine Formulardaten, kein Rohinhalt

Rohbeispiel (* Obwohl sich der Pfad von der Bildschirmaufnahme unterscheidet, können beide keine Post-Daten 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 habe ich entdeckt (durch Differenzieren des Header-Inhalts)

Rohbeispiel (* Obwohl sich der Pfad von der Bildschirmaufnahme unterscheidet, können beide keine Post-Daten 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 2 Beispielen

• Erfolgreich ist die Verwendung der JQuery-Bindung, während Fehler bei der Verwendung von HTTPS von nodejs + browserify auftritt. Ich finde jedoch immer noch einen Weg, um zu überprüfen, ob dies ein Problem ist oder nicht (nicht getestet)

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

• Großbuchstabe vs Feld für kleinere Buchstabenüberschriften (

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

  • Acceptvs accept(nicht getestet)

HINWEIS: (5) (7)

Trotzdem bin ich mir nicht sicher, warum der erste cin content-typeKleinbuchstaben ist.

ANMERKUNG 1)

Was ich versucht habe

Ich habe Firefox mit Firebug ausprobiert. Es kann meine Nutzlast anzeigen. Die Antwort vom Server kann jedoch nicht analysiert werden: '(

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

Link zu einer Übersicht über das Debuggen von HTTP-Anforderungen über die Befehlszeile. NOTIZ 3)

Wrapper, den ich benutze

Ich habe diese Methode von nodejs mit einem Versprechen aufgerufen . Unten ist ein Ausschnitt, der eine Option zeigt, 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 überprüft, dass der Buchstabe ckeinen Einfluss auf den Chrome-Debugger hat. Hier ist die Geige . Ich habe versucht, dieselbe Anfrage XMLHttpRequestmit einem Brief nachzuahmen c. Ich kann weiterhin Formulardaten im Debugger überprüfen.
• (2) Link zum vollständigen Quellcode
• (3) Link zu einem Kern von mir über Skripte zum Testen von HTTP (s) -Anfragen
• (4) Formatieren Sie die Frage zur Lesbarkeit neu
• (5) Beispiele verwenden nach der Codeüberprüfung nicht dieselbe Bindung
• (6) Fügen Sie ein Beispiel für einen Rohheader hinzu
• (7) Fügen Sie eine Vergleichssitzung hinzu

In Chrome v61 und v62 gab es auf allen Plattformen einen Regressionsfehler, der dieses Verhalten verursachte, wenn die Antwort (unter anderem) 302 war. Dieser Fehler wurde in v63stable behoben, der am 6. Dezember 2017 für alle Desktop-Plattformen veröffentlicht wurde.

Automatische Updates werden schrittweise durchgeführt. Wenn Sie jedoch zu "Hilfe" / "Über Google Chrome" gehen, wird das Update erzwungen und Sie erhalten eine Schaltfläche zum Neustart. Gelegentlich ist es erforderlich, den gesamten Chrome-Prozess abzubrechen und manuell neu zu starten, um das Update zu erhalten.

Der (jetzt geschlossene) Fehlerbericht ist hier . Die Release-Ankündigung ist hier .

Dies ist natürlich nicht die Ursache für die Ausgabe des Originalplakats im Jahr 2015, aber die Suche nach der Ausgabe hat mich hierher geführt. Beachten Sie auch, dass dies nicht nur ein OS X-Problem ist.

Wenn Ihre Anwendung einen 302-Statuscode und keine Nutzdaten in Chrome Devtools zurückgibt, ist dies möglicherweise der Fall dieser Chrome-Fehler auf .

Wenn Sie sich in der Entwicklung befinden oder dies eine URL ist, die nichts kaputt macht, besteht eine schnelle, sehr praktische Problemumgehung darin, Ihren serverseitigen Code so zu ändern, dass eine 200 gesendet wird, beispielsweise in PHP, das Sie möglicherweise hinzufügen:

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

das sendet einen 200 Statuscode. Dies umgeht den "302-Fehler" - bis er behoben ist.

ps Per @ leo-hendry unten, Canary hat das Update ab Dezember 2017, aber wenn Sie keinen anderen Grund haben, Canary auszuführen, lohnt es sich nicht, einen anderen Browser nebeneinander auszuführen, da dies die Hauptversion ist sollte bald herauskommen.

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

Der folgende Screenshot stammt aus Chrome 63 unter Windows. Sie können den Abschnitt mit den Anforderungsnutzdaten wie erwartet anzeigen.

Folgendes sehe ich in Chrome 65 Beta, das auf einem Mac ausgeführt wird. Beachten Sie, dass der Abschnitt mit den Anforderungsnutzdaten fehlt.

Kann ich zu Recht davon ausgehen, dass der Fehler nicht behoben ist, oder sollte ich noch etwas überprüfen?

Ich habe gerade bemerkt, dass Sie keine POST-Daten sehen können, wenn Sie "Doc" aus den Filtern im Chrome-Debugger auswählen (neben "Alle", "Xhr", "CSS", "JS"). Es wird angezeigt, wenn Sie "Alle" auswählen.

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

Weder die Formulardaten noch die Registerkarte Payload werden angezeigt. In meinem Szenario poste ich ein Formular mit dem Enctype "multipart / form-data" an einen Iframe (Übermittlung einer Bilddatei über https an denselben Ursprung). Es funktioniert wie erwartet, aber ich weiß nicht, wie ich die Daten in Chrome richtig debuggen soll, wenn sie überhaupt nicht angezeigt werden. Ich könnte die Daten in PHP sichern, aber das ist unnötig kompliziert und es fehlt völlig der Sinn der Verwendung der Konsole. Ich habe die oben vorgeschlagenen Lösungen gelesen, aber es ist mir nicht gelungen, dieses Problem zu beseitigen. (Der Antwortcode ist übrigens 200, nicht 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
    )
)

Ihr Code sieht in Ordnung aus. Haben Sie die Chrome-Konsole auf Fehler überprüft? Wenn Sie Zugriff auf den Server haben (und davon ausgehen, dass er httpdunter Linux ausgeführt wird), 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

Obwohl dies nicht die Antwort auf die ursprüngliche Frage ist, ersetzt meine Alternative die ursprüngliche Implementierung durch die Kombination aus Formulardaten , es6-Versprechen und isomorphem Abruf zu

Alle Pakete können von npm heruntergeladen werden.

Es funktioniert charmant.