this および that をチェックアウトしました。ただし、私のデバッガは次のようになります。
フォームデータなし、生のコンテンツなし
生の例(*パスは画面キャプチャとは異なりますが、どちらも投稿データを読み取ることができません)
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 binding を使用し、失敗したものは nodejsからのHTTPS + browserifyを使用しています。しかし、私はまだこれが問題かどうかを確認する方法を見つけています(テストされていません)
X-Requested-With: XMLHttpRequest
がありません。ただし、このヘッダーをリクエストに追加してもこの問題は修正されません(テスト済み)
大文字のヘッダーと小文字のヘッダーフィールド(
content-type
およびContent-type
。しかし、この違いは、 fiddle here (テスト済み)で試みた私の問題の根本的な原因ではありません
Accept
vs accept
(テストなし)
注:(5)(7)
それでも、content-type
の最初のc
が小文字である理由はわかりません。
注:(1)
Firebugを使用してFirefoxで試しました。ペイロードを表示できます。ただし、サーバーからの応答を解析できません: '(
WebサーバーはHTTPSプロトコルで実行されているため、wiresharkでパケットをキャプチャできません。 POSTリクエストをデバッグするための提案はありますか?ありがとう。
コマンドラインを介したHTTP(s)リクエストのデバッグについて Gist へのリンク。注3)
私はラップを持っています nodejsからのこのメソッド promise呼び出しで。以下は、私が使用したオプションを示すスニペットです。
/**
* 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)
Chrome v61およびv62の回帰バグは、応答が(とりわけ)302の場合にこの動作を引き起こしました。これは、12月6日にすべてのデスクトッププラットフォームにリリースされたv63安定版で修正されました2017年。
自動更新は段階的に行われますが、「ヘルプ」/「Google Chromeについて」に移動すると、更新が強制的にダウンロードされ、再起動するボタンが表示されます。場合によっては、すべてのChromeプロセスを強制終了し、手動で再起動して更新を取得する必要があります。
(現在クローズされている)バグレポートは here です。リリースのお知らせは here です。
明らかに、これは2015年の元のポスターの問題の原因ではありませんが、問題を検索することでここに導かれました。また、これは単なるOS Xの問題ではありません。
アプリケーションが302ステータスコードを返し、Chrome Devtoolsにペイロードデータがない場合、 このChromeバグ である可能性があります。
開発中、またはこれが何も壊さないURLである場合、迅速で非常に実用的な回避策は、サーバーサイドコードを変更して、たとえばPHPに200を送信することです。
die("premature exit - send a 200");
200ステータスコードを送信します。これは、修正されるまで「302バグ」を回避します。
追伸以下の@ leo-hendryに従って、Canaryは2017年12月の時点で修正されていますが、Canaryを実行する別の理由がない場合、メインラインリリースがそうであるように、別のブラウザーを並べて実行することは価値がありませんすぐに出てきます。
POSTデバッガー([すべて]、[Xhr、Css、JS]の隣)のフィルターから[Doc]を選択すると、Chromeデータが表示されないことに気付きました。 「すべて」を選択すると表示されます。
おそらくChromeコンソールで同じ問題が発生しました(Chrome 69)
フォームデータもペイロードタブも表示されていません。私のシナリオでは、POST enctypeが「multipart/form-data」のフォームをiframeにフォームします(httpsを介して同じOriginに画像ファイルを送信します)。期待どおりに動作しますが、chromeのデータがまったく表示されない場合に適切にデバッグする方法がわかりません。 IcouldはPHPにデータをダンプしますが、それは不要で複雑であり、コンソールを使用するポイントを完全に失います。上記の推奨ソリューションを読みましたが、この問題を取り除くことができませんでした。 (応答コードは302ではなく200 btwです)。
$_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
)
)
コードは問題ないようです。 Chromeコンソールのエラーを確認しましたか?サーバーにアクセスできる場合(そして、Linuxでhttpd
であると想定している場合)、小さなCGIシェルスクリプトを作成して、その最後のヘッダーとデータを検査できます。
#!/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