google chrome - other - ¿La carga HTTP POST no está visible en el depurador de Chrome?

https://chrome:inspect

Question

He comprobado this y that . Sin embargo, mi depurador se ve a continuación.

Ejemplo de falla

.

Sin datos de formulario, sin contenido sin procesar

Ejemplo sin formato (* Aunque la ruta es diferente de la captura de pantalla, ambos no pueden leer los datos publicados)

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

NOTA: (6)

Ejemplo exitoso

Las diferencias entre ellos las he detectado (al diferenciar el contenido del encabezado)

Ejemplo sin formato (* Aunque la ruta es diferente de la captura de pantalla, ambos no pueden leer los datos publicados)

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

NOTA: (6)

Diferencia de encabezado entre 2 ejemplos

• Uno exitoso está utilizando el enlace de Jquery, mientras que el fallo usa uno HTTPS de nodejs + browserify. Sin embargo, todavía estoy encontrando una manera de verificar si esto es un problema o no (no probado)

• Falta X-Requested-With: XMLHttpRequest . Sin embargo, agregar este encabezado nuevamente a la solicitud no soluciona este problema (Probado)

• Encabezado de capital vs campo de encabezado de letra más pequeña (

  • content-type Content-type y content-type Content-type . Sin embargo, esta diferencia no es la causa principal de mi problema, como se intentó en violín aquí (Probado)

  • Accept vs accept (no probado)

NOTA: (5) (7)

Aún así, no estoy seguro de por qué la primera c en content-type está en minúscula.

NOTA 1)

Lo que he intentado

He intentado en Firefox con firebug. Es capaz de mostrar mi carga útil. Sin embargo, no puede analizar la respuesta del servidor: ''(

Dado que el servidor web se está ejecutando en el protocolo HTTPS, no puedo capturar paquetes por wireshark. ¿Alguna sugerencia para depurar solicitudes POST? Gracias.

Enlace a una idea general sobre la depuración de la solicitud HTTP a través de la línea de comandos. NOTA 3)

Envoltorio que estoy usando

He envuelto este método de nodejs con una promesa de llamadas. A continuación se muestra un fragmento que muestra una opción que he usado.

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

Fuente completa aquí

NOTA 2)

Actualizar

• (1) He verificado que la letra c no afecta al depurador de cromo. Aquí está el violín . He intentado imitar la misma solicitud con XMLHttpRequest con la letra c . Todavía puedo verificar los datos del formulario en el depurador.
• (2) Enlace al código fuente completo
• (3) Enlace a un gist sobre scripts para probar la solicitud HTTP (s)
• (4) Reformatear la pregunta para facilitar la lectura
• (5) Los ejemplos no usan el mismo enlace después de revisar el código
• (6) Agregar ejemplo de encabezado sin formato
• (7) Agregar una sesión de comparación

Answer 1

Acabo de notar que no puede ver los datos POST si selecciona "Doc" de los filtros en el depurador de Chrome (junto a Todos, Xhr, Css, JS ...). Se muestra si selecciona "Todos".

Answer 2

Aunque esta no es la respuesta de la pregunta original, mi alternativa es reemplazar la implementación original con el combo de datos de formulario , es6-promise y isomorphic -fetch

Todos los paquetes pueden descargarse desde npm.

Funciona con encanto

Answer 3

Hubo un error de regresión en Chrome v61 y v62 en todas las plataformas que causó este comportamiento cuando la respuesta es (entre otras) un 302. Esto se solucionó en v63 estable que se lanzó en todas las plataformas de escritorio el 6 de diciembre de 2017.

Las actualizaciones automáticas se escalonan, pero ir a "Ayuda" / "Acerca de Google Chrome" lo obligará a descargar la actualización y le dará un botón para reiniciar. Ocasionalmente, es necesario eliminar todo el proceso de Chrome y reiniciarlo manualmente para obtener la actualización.

El informe de error (ahora cerrado) está here . El anuncio de lanzamiento está here .

Claramente, esta no es la causa del problema del póster original en 2015, pero las búsquedas del problema me llevaron aquí. También tenga en cuenta que esto no es solo un problema de OS X.

Answer 4

Probablemente tuve el mismo problema con la consola de Chrome (Chrome 69)

No se muestran ni los formularios ni la pestaña de carga útil. En mi escenario, PUBLICO un formulario con enctype "multipart / form-data" a un iframe (enviando un archivo de imagen a través de https al mismo origen). Funciona como se esperaba, pero no sé cómo depurar los datos en Chrome correctamente cuando no aparece en absoluto. Podría volcar los datos en PHP, pero eso es innecesariamente complicado y me falta totalmente el punto de usar la consola. He leído las soluciones sugeridas anteriormente, pero no pude deshacerme de este problema. (El código de respuesta es 200 por cierto, no 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
    )
)

Answer 5

Si esto es un error, puede comportarse de manera diferente en Mac frente a Windows.

La siguiente captura de pantalla es de Chrome 63 en Windows. Puede ver la sección de solicitud de carga útil como se esperaba.

Esto es lo que veo en Chrome 65 Beta ejecutándose en Mac. Observe que falta la sección de carga útil de la solicitud.

¿Estoy en lo cierto al suponer que el error no está solucionado o hay algo más que debería estar revisando?

Answer 6

Si su aplicación devuelve un código de estado 302 y no hay datos de carga útil en Chrome Devtools, es posible que se encuentre con este error de Chrome .

Si está en desarrollo o esta es una URL que no romperá nada, una solución rápida y muy práctica es modificar el código del lado del servidor para enviar un 200, por ejemplo en PHP, puede agregar:

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

que envía un código de estado 200. Esto funciona alrededor del "error 302", hasta que se solucione.

ps Según @ leo-hendry a continuación, Canary tiene la solución a partir de diciembre de 2017, pero si no tiene otra razón para ejecutar Canary, ejecutar otro navegador en paralelo no valdrá la pena, ya que el lanzamiento de la línea principal debería salir pronto.

Answer 7

Tu código se ve bien. ¿Has revisado la consola de Chrome en busca de errores? Si tiene acceso al servidor (y suponiendo que es httpd en Linux), puede hacer un pequeño script de shell CGI para inspeccionar los encabezados y los datos en ese extremo:

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