web-dev-qa-db-fra.com

HTTP POST charge utile non visible dans le débogueur Chrome?

J'ai vérifié ceci et cela . Cependant, mon débogueur ressemble à celui ci-dessous.

Exemple d'échec

 No form data, No raw content .

Pas de données de formulaire, pas de contenu brut

Exemple brut (* Bien que le chemin d'accès soit différent de celui de la capture d'écran, les deux ne sont pas en mesure de lire les données de publication)

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)

Exemple de réussite

 Some of them are able to work

Différences entre eux que j'ai repérées (en différenciant le contenu de l'en-tête) 

Exemple brut (* Bien que le chemin d'accès soit différent de celui de la capture d'écran, les deux ne sont pas en mesure de lire les données de publication)

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)

En-tête Différence entre 2 exemples

  • On réussit utilise Jquery binding while échec, on utilise HTTPS de nodejs + browserify. Cependant, je suis toujours en train de trouver un moyen de vérifier s'il s'agit d'un problème ou non (non testé)

  • X-Requested-With: XMLHttpRequest manquant. Cependant, l'ajout de cet en-tête à la demande ne résout pas ce problème (testé)

  • En-tête Capital vs Champ d'en-tête de lettre plus petite

    • content-type et Content-type. Cependant, cette différence n’est pas la cause fondamentale de mon problème, comme nous l’avons essayé dans violon ici (testé)

    • Accept vs accept (non testé)

NOTE: (5) (7)

Néanmoins, je ne suis pas sûr de savoir pourquoi la première c dans content-type est en minuscule.

NOTE 1)

Ce que j'ai essayé

J'ai essayé sur Firefox avec firebug. Il est capable de montrer ma charge utile. Cependant, il ne peut pas analyser la réponse du serveur: '(

Étant donné que le serveur Web s'exécute dans le protocole HTTPS, je ne peux pas capturer les paquets par Wireshark. Des suggestions pour le débogage des demandes POST? Merci.

Lien vers un Gist à propos du débogage de la demande HTTP (s) via la ligne de commande. NOTE 3)

Wrapper j'utilise

J'ai wrap cette méthode de nodejs avec une promesse d'appels. Ci-dessous, un extrait montre une option que j'ai utilisée.

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

Source complète ici

NOTE 2)

Mettre à jour

  • (1) J'ai vérifié que la lettre c n'affecte pas le débogueur Chrome. Voici le violon . J'ai essayé d'imiter la même demande avec XMLHttpRequest avec la lettre c. Je peux toujours vérifier les données de formulaire dans le débogueur.
  • (2) Lien vers le code source complet
  • (3) Lien vers un Gist from me à propos des scripts pour tester la requête HTTP (s)
  • (4) reformater la question pour la lisibilité
  • (5) Les exemples n'utilisent pas la même liaison après la révision du code
  • (6) Ajouter un exemple d'en-tête brut
  • (7) Ajouter une session de comparaison 
google-chromeposthttp-postgoogle-chrome-devtools
59
Mond Wan

Un problème de régression dans Chrome v61 et v62 sur toutes les plates-formes a provoqué ce problème lorsque la réponse est (entre autres) un 302. Ce problème a été résolu dans la version stable v63 qui a été publiée pour toutes les plates-formes de bureau le 6 décembre 2017. 

Les mises à jour automatiques sont échelonnées, mais aller dans "Aide"/"À propos de Google Chrome" l'obligera à télécharger la mise à jour et vous donnera un bouton pour le redémarrer. Il est parfois nécessaire de tuer tous les processus Chrome et de le redémarrer manuellement pour obtenir la mise à jour.

Le rapport de bogue (maintenant fermé) est ici . L'annonce de la sortie est ici .

Clairement, ce n'est pas la cause du problème de l'affiche originale en 2015, mais la recherche du problème m'a conduit ici. Notez également qu'il ne s'agit pas simplement d'un problème d'OS X.

128
Leo Hendry

Je viens de remarquer que vous ne pouvez pas voir les données POST si vous sélectionnez "Doc" dans les filtres du débogueur Chrome (à côté de Tous, Xhr, Css, JS ...). Il montre si vous sélectionnez "Tous".

3
geert3

S'il s'agit d'un bogue, il se peut que son comportement soit différent sous Mac et sous Windows.

La capture d'écran ci-dessous provient de Chrome 63 sous Windows. Vous pouvez voir la section de charge de la demande comme prévu.

 Good Example

Voici ce que je vois sur Chrome 65 Beta sous Mac. Notez que la section de charge utile de la demande est manquante.

 Bad example

Ai-je raison de supposer que le bogue n'est pas corrigé ou y a-t-il autre chose que je devrais vérifier?

1
Chad Juliano

Votre code a l'air bien. Avez-vous vérifié les erreurs dans la console Chrome? Si vous avez accès au serveur (et en supposant qu'il s'agisse de httpd sous Linux), vous pouvez créer un petit script CGI Shell pour inspecter les en-têtes et les données à cette fin:

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

J'ai probablement eu le même problème avec la console Chrome (Chrome 69)

Ni l'onglet formdata ni les données utiles ne montrent . Dans mon scénario, je POST un formulaire avec enctype "multipart/form-data" à une iframe (envoi d'un fichier image par https à la même origine). Cela fonctionne comme prévu, mais je ne sais pas comment déboguer correctement les données en chrome quand elles ne s'affichent pas du tout. Je pourrais vider les données dans PHP, mais ce n'est pas compliqué et compliqué, et il est totalement inutile de se servir de la console. J'ai lu les solutions suggérées ci-dessus mais je n'ai pas réussi à résoudre ce problème. (Le code de réponse est 200 BTW, pas 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.