Полезная нагрузка HTTP POST не отображается в отладчике Chrome?

Я проверил этот и который. Однако мой отладчик выглядит ниже.

Пример сбоя

Нет данных формы, Нет сырого содержимого.

Нет данных формы, без сырого содержимого

Исходный пример (* Хотя путь отличается от захвата экрана, оба из них не могут читать пост-данные)

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

ПРИМЕЧАНИЕ: (6)

Успешный пример

Некоторые из них могут работать

Различия между ними, которые я заметил (путем различения содержимого заголовка)

Исходный пример (* Хотя путь отличается от захвата экрана, оба из них не могут читать пост-данные)

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

ПРИМЕЧАНИЕ: (6)

Разница заголовка между двумя примерами

  • Успешный использует привязку JQuery, в то время как сбой при использовании HTTPS из nodejs + браузер. Тем не менее, я все еще нахожу способ проверить, является ли это проблемой или нет (не проверено)

  • Отсутствует X-Requested-With: XMLHttpRequest. Однако добавление этого заголовка обратно в запрос не устраняет эту проблему (протестировано)

  • Заголовок заголовка против поля заголовка меньшего письма (

    • content-type и content-type. Однако это различие не является основной причиной моей проблемы, как было проверено в скрипка здесь (протестировано)

    • Accept vs Accept (не проверено)

ПРИМЕЧАНИЕ: (5) (7)

Тем не менее, я не уверен, почему первый c в content-type находится в малом письме.

ПРИМЕЧАНИЕ: (1)

Что я пробовал

Я пробовал Firefox с firebug. Он может показывать мою полезную нагрузку. Однако он не может разобрать ответ с сервера: '(

Поскольку веб-сервер работает в протоколе HTTPS, я не могу захватить пакеты с помощью wirehark. Любое предложение для отладки запросов POST? Благодаря.

Ссылка на gist об отладке запроса HTTP (ов) через командную строку. ПРИМЕЧАНИЕ: (3)

Wrapper Я использую

У меня есть wrap этот метод из nodejs с призывом к обещанию. Ниже приведен фрагмент, который я использовал.

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

Полный источник здесь

ПРИМЕЧАНИЕ: (2)

Update

  • (1) Я подтвердил, что письмо c не влияет на хром-отладчик. Вот скрипка. Я попытался воспроизвести один и тот же запрос с помощью XMLHttpRequest с буквой c. Я все еще могу проверить данные формы в отладчике.
  • (2) Ссылка на полный исходный код
  • (3) Ссылка на gist from me о скриптах для проверки запроса HTTP (s)
  • (4) Переформатировать вопрос для удобочитаемости
  • (5) Примеры не используют одну и ту же привязку после просмотра кода
  • (6) Добавить пример исходного заголовка
  • (7) Добавить сеанс сравнения
+38
источник поделиться
5 ответов

Хотя это не ответ на исходный вопрос, моя альтернатива заменяет исходную реализацию комбо form-data​​strong > , es6-prom и изоморфной -fetch

Все пакеты могут загружаться с npm.

Он работает великолепно.

0
источник

В версиях Chrome v61 и v62 произошла ошибка регрессии на всех платформах, вызвавших такое поведение, когда ответ (среди прочих) - 302. Это исправлено в версии v63, которая была выпущена на все настольные платформы 6 декабря 2017 года.

Автоматические обновления поэтапно, но переход к "Справка" / "О Google Chrome" заставит его загрузить обновление и дать вам кнопку для перезапуска. Иногда необходимо убить весь процесс Chrome и перезагрузить его вручную, чтобы получить обновление.

Отчет об ошибке (теперь закрыт) здесь. Объявление о выпуске здесь.

Понятно, что это не причина первоначального выпуска постеров еще в 2015 году, но поиски этой проблемы привели меня сюда. Также обратите внимание, что это не просто проблема с OS X.

+122
источник

Если ваше приложение возвращает код состояния 302 и данные о полезной нагрузке в Chrome Devtools, вы можете ударить эту ошибку Chrome.

Если вы находитесь в разработке или это URL-адрес, который ничего не сломает, быстрый, очень практичный способ обхода проблемы заключается в изменении кода на стороне сервера для отправки 200, например, в PHP, который вы можете добавить:

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

который отправляет код состояния 200. Это работает вокруг "ошибки 302" - пока она не будет исправлена.

p.s. Per @leo-hendry ниже, у Canary есть исправление по состоянию на декабрь 2017 года, но если у вас нет другой причины запуска Canary, запуск другого браузера бок о бок не будет стоить того, поскольку основной релиз должен скоро выйдет.

+14
источник

Я только заметил, что вы не можете видеть данные POST, если вы выбрали "Doc" из фильтров в отладчике Chrome (рядом со All, Xhr, Css, JS...). Он показывает, выбираете ли вы "Все".

+1
источник

Ваш код выглядит нормально. Вы проверили консоль Chrome на наличие ошибок? Если у вас есть доступ к серверу (и предполагается, что он равен httpd в Linux), вы можете сделать небольшую оболочку CGI script для проверки заголовков и данных с этой целью:

#!/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
источник

Посмотрите другие вопросы по меткам или Задайте вопрос