Chromeデバッガで「注意：暫定的なヘッダが表示される」
Googleのクロムインスペクタ（F12）を使ってダウンロードしたリソースを見ると、奇妙な注意メッセージがありました。
注意暫定ヘッダーが表示されます
ネットワークパネル：暫定要求ヘッダーについての注意を追加します しかし、それを完全には理解できませんでした。関連する質問が見つかります Chromeブロックリクエスト と XMLHttpRequestを読み込めません。アンロードされたリソースには注意が表示されます。暫定ヘッダーは表示されます 。
最初の質問 と同様に、私のリソースはブロックされましたが、後で同じリソースが自動的にロードされました。 2番目の質問 とは異なり、私は何も修正したくありません。このメッセージが何を意味するのか、そしてなぜそれを受け取ったのかを知りたいのです。
リソースが拡張機能（私の場合はAdBlock）によってブロックされている可能性があります。
そのリソースを検索する要求が行われたことがないため、メッセージが表示されます。したがって、表示されているヘッダーは実際のものではありません。参照した問題で説明したように、実際のヘッダーはサーバーが応答するときに更新されますが、要求がブロックされた場合は応答がありません。
私のリソースをブロックしている拡張機能について私が見つけた方法は、Chromeのnet-internalsツールを使うことでした。
- アドレスバーに
chrome://net-internalsと入力してEnterキーを押してください。 - 問題を示しているページを開きます。
- Net-internalsに戻って events（###） をクリックし、テキストフィールドを使用してリソースに関連するイベントを見つけます（URLの一部を使用）。
- 最後に、イベントをクリックして、表示された情報が何かを教えてくれるかどうか確かめてください。
実際のリクエストが送信されないときに起こると思います。通常、キャッシュされたリソースをロードしているときに起こります。
私はこの問題に遭遇しました、そして、私はどうにか答えまたは質問のどちらでも上記で言及されない特定の原因を特定することができました。
SSLでフルjsスタック、角度付きフロントエンド、ノードバックエンドを実行しています。APIはポート8081で実行されている別のドメイン上にあるため、APIからセッションCookieを削除するときにCORS要求とwithCredentialsを実行しています。
つまり、私のシナリオは次のとおりです。POST request、ポート8081へのwithCredentialsにより、インスペクタで "注意：暫定ヘッダーが表示されています"というメッセージが表示され、もちろん要求もすべてブロックされました。
私の解決策は、443の通常のSSLポートから8081のノードのSSLポートにリクエストをプロキシ転送するようにApacheを設定することでした（ノードはprodでrootとして走らせることができないので、より高いポートになければなりません）。そのため、Chromeは従来とは異なるSSLポートへのSSLリクエストを好まないが、おそらくそれらのエラーメッセージはより具体的なものになる可能性がある。
HTTP/2プッシュされたリソース は@wvegaが/に投稿したのと同じ理論でインスペクタでProvisional headers are shownを生成します - 上の彼の答え 。
例： サーバーがリソースをクライアントにプッシュしたので（クライアントが要求する前に）、ブラウザはリソースをキャッシュしているため、クライアントは決して要求を出しません。 ;だから….
...サーバーが応答すると実際のヘッダーが更新されますが、要求がブロックされた場合は応答がありません。
これは、 （クロスOriginリクエストのみ） が発生する可能性もあります。 サイト分離 という新しい機能があるためです。
このページでは問題と回避策について詳しく説明しています 。これはchromeでchrome://flags/#site-isolation-trial-opt-outに行き、その設定を "Opt-out"に変更してchromeをリロードすることです。
それは 既知の問題 です。しかしそのページはそれがクロム68で固定されていると言う、しかし私はクロム68を動かしていて、そして私はまだ問題を抱えている。
クロムv72 +のために私のためにそれを解決したのはこれだけでした：
chrome://flags/に行き、この3つのフラグを無効にしてください
- サイトの分離を無効にする
- ネットワークサービスを有効にする
- ネットワークサービスをインプロセスで実行
あるいは、コマンドラインから実行することもできます。
chrome --disable-site-isolation-trials --disable-features=NetworkService,NetworkServiceInProcess
なぜこれが起こるのですか？
グーグルは彼らのChromiumエンジンをモジュール構造にリファクタリングしているようで、そこでは異なるサービスが独立したモジュールとプロセスに分けられるでしょう。彼らはこのプロセスを「サービス化」と呼びます。ネットワークサービスは最初のステップです、Uiサービス、アイデンティティサービスとデバイスサービスは来ています。 Googleは Chromiumプロジェクトサイト で公式情報を提供しています。
それを変えるのは危険ですか？
例はネットワーキングです。ネットワークサービスを入手したら、安定性/セキュリティの向上のためにプロセス外で実行するか、 またはリソースに制約がある場合はインプロセス を選択できます。 ソース
私の状況は クロスオリジン relatedです。
シチュエーション： OPTIONSまたはGETのように、ブラウザーは実際の要求を送信する前にPOST要求を送信します。バックエンド開発者はOPTIONSリクエストを処理するのを忘れ、サービスコードを通過させてしまい、処理時間が長すぎます。私がaxiosの初期化で書いたタイムアウト設定よりも長く、それは5000ミリ秒です。そのため、実際の要求を送信できず、provisional headers are shown問題が発生しました。
解決策： OPTIONSリクエストに関しては、バックエンドAPIは結果を返すだけで、リクエストを速くし、実際のリクエストをタイムアウト前に送信することができます。
私の答えがあなたを助けるのに間に合うかどうか疑いますが、他の人がそれを役に立つと思うかもしれません。私が作成したjQuery Ajax Postスクリプトでも同様の問題が発生しました。
それは私が記事を発射するために使用していたAタグのhref属性にタイプミスがあることがわかった。 href = " javacsript :;"と入力しました。 （ 's'と 'c'を逆にします）..これはポストが発砲しようとしている間にスクリプトにページをリフレッシュさせようとしました。タイプミスを修正し、それは私のために完璧にうまくいきました。
これはごく最近（実際には）実際に起きたので、AJAX呼び出しがサーバーに送信され、Chromeは「注意：暫定ヘッダーが表示されています」というメッセージを表示します。サーバサイドのPHPスクリプトでは、与えられたシナリオに応じてほとんど瞬時に、または数秒かかるMySQLクエリがあります。クエリが完了するまで、サーバーの応答がブラウザに返送されません。時間がかかるクエリ（合計数秒まで）が行われ、応答が返送されない場合にのみ、このエラーが発生します。
私のシナリオでは、天気モデルの出力用に何百もの列を追加/削除してテーブルを変更しなければならないという非常にまれな可能性があります。
これが起こる一般的な理由は、あなたがイベントを追跡していて、デフォルトのアクションを妨げていない場合です。たとえば、クリックイベントがある場合は、次のものを含めます。
e.preventDefault();
または
return false;
そうでない場合は、あなたのWebコンソールのNetworkタブに暫定的なヘッダの警告と "cancelled"ステータスが表示されます。
無効なHTTP Authorizationヘッダーを送信していたときに、この問題が発生しました。私はそれをbase64でエンコードするのを忘れました。
これは、Ajaxリクエストを送信したと同時に、location.hrefなどを使用して自分のページを別のページに移動したためと考えられます。そのため、前の要求は失敗しました。
私の場合、それは単にリソースへの誤った設定パスでした（svg/img）
私はAJAX呼び出しでこの問題に遭遇しました。私はwvegaのアドバイスに従い、親ノードで待機しているページ内の別のclickイベントハンドラを最終的に決定するためのchrome://net-internalsによるデバッグについてのヒントに従って、ブラウザを同じURLにナビゲートさせていました。
解決策は、フォーム送信ボタンのclickハンドラーにevent.stopPropagation()を追加して、クリックがDOMを膨らませて進行中のAJAX要求をキャンセルしないようにすることです（submitのformハンドラーを介して開始されます）。
あなたのコードの次のコードを使用してください。
header('Cache-Control: no-cache, no-store, must-revalidate');
header('Pragma: no-cache');
header('Expires: 0');
これは私のために働きます。
私はこれに遭遇し、私がhttpsからhttpに切り替えたときにそれは消えました。私たちがdevで使っているSSL証明書は第三者によって検証されていません。それらはローカルで生成された開発者証明書です。
Chrome CanaryとFirefoxでも同じ呼び出しがうまく機能します。これらのブラウザは、ChromeほどSSL証明書に関して厳格ではないようです。 Chromeでは「注意：暫定ヘッダー...」というメッセージが表示されて呼び出しが失敗します。
私たちが段階的かつ正当な方法で合法的なSSL証明書を使用するとき、私たちはもはやChromeではこの振る舞いを見ないだろうと私は思います/希望します。
これは、サーバーへの接続数がChromeのサーバーあたりの最大接続数の6の制限を超えたときに発生しました。
私が見たもう一つの可能なシナリオ - まったく同じ要求が数ミリ秒後に再び送信されています（たぶんクライアント側のバグが原因です）。
その場合、最初のリクエストのステータスが「キャンセル」され、待ち時間がわずか数ミリ秒になることもわかります。
この警告メッセージは、応答が無効なためブラウザによって破棄された場合にも発生します。
私の場合、リクエストがサーバーに正しく送信された後、サーバー側のコードがエラーを生成し、私のカスタムエラー処理がHTTPステータスメッセージフィールドにエラーメッセージを返しました。しかし、エラーメッセージ（ここで説明されている http://aspnetwebstack.codeplex.com/workitem/1386 ）に無効な文字が含まれているため、このエラーはクライアント側で受信されず、応答ヘッダーが破損していました。
エラーのために変更を加えた後で、require jsのためにmain.jsを2度目にロードしようとしたときにこの問題が発生しました。私は開発者ツールの設定で「キャッシュを無効にする（DevToolsが開いているとき）」をオンにしました。それが魅力でした。
私がダウンロードリンクを持っていて、それをクリックした後にjqueryでクリックをキャッチしてajaxリクエストを送信しようとしていたとき、これは私のために起こっていました。問題は、ダウンロードリンクをクリックしているときに、そのページが表示されていなくてもページから離れていることです。ファイル転送が行われない場合は、要求されたページが表示されます。そのため、この問題を防ぐためにtarget = "_ blank"を設定しました。
ポップアップでページを印刷しようとしたときにこのエラーが発生しました。印刷ダイアログが表示され、それはまだマスターページにもメッセージを表示してバックグラウンドで待機していたときにポップアップで私の印刷の受け入れまたはキャンセルを待っていた 注意暫定ヘッダーが表示されます 別のリンクをクリックしようとしたとき.
私の場合の解決策は、ポップアップウィンドウの<body>で実行していたwindow.print ();スクリプトを削除して、印刷ダイアログを表示しないようにすることでした。
この問題は、webpack-hot-middlewareのようないくつかのパッケージを使用し、同時に複数のページを開くときにも発生します。 webpack-hot-middlewareは、コードの変更を監視してページを更新するために各ページの接続を作成します。各ブラウザにはmax-connections-per-serverの制限があり、これはChromeでは6です。したがって、Chromeで既に6ページ以上開いている場合は、いくつかのページを閉じるまで新しいリクエストがそこにハングします。
私の2セントを投げ込むだけです。私はCORSリクエストと完全なRESTful Webサービスを使ってWebアプリケーションを書いています。手渡されていない例外またはPHP Errorがスローされたときに、chromeがこのエラーをスローすることがわかりました。他の誰かが問題に遭遇しただけの場合。私はこれが起こったとき私はChromeアプリ "Postman - Rest Client"を起動して全く同じリクエストを実行することができるがChromeアプリでは実際にこれの代わりにスローされるPHP Errorを得るでしょう説明的ではないエラーです。
私の場合は、送信リクエストで送信していたボディパラメータと、ボディパラメータに応じて作成したロジックが間違っていたため、応答を送信できませんでした。だから私はこのエラーを受けていました。
example: post request body (a: alsldfjfj) which I was sending
しかし、私は "a"の代わりに "b"を検証するためのコードを書きました。
HTTPSでホストされているWebサイトがHTTPでホストされているWebApiへの呼び出しを呼び出すと、「注意：暫定ヘッダーが表示されます」というメッセージが表示されることがあります。すべてのApiがHTTPSの場合は、すべてチェックできます。ブラウザは、安全でないリソースへの呼び出しを防ぎます。 HTTPでドメイン処理するためにFETCH APIを使用すると、コード内に同様のメッセージが表示されることがあります。
混合コンテンツ： ' https://website.com 'のページはHTTPS経由でロードされましたが、安全でないリソース ' http://webapi.com 'が要求されました。このリクエストはブロックされました。コンテンツはHTTPS経由で配信する必要があります。
私のMEANアプリにも同じような問題がありました。私の場合、この問題は1回の取得要求でのみ発生していました。私はadblockを削除しようとした、キャッシュをクリアしようとしたし、別のブラウザで試した。何も助けなかった。
最後に、APIが巨大なJSONオブジェクトを返そうとしていたことを私は理解しました。私が小さな物を送ろうとしたとき、それはうまく働いていました。最後に、JSONの代わりにバッファを返すように実装を変更しました。
この場合、expressJSがエラーをスローするようにします。
私の場合、原因はAdBlockの拡張でした。
サーバーへのリクエストが処理され、レスポンスが返ってきましたが、Devツールに "暫定ヘッダー.."が表示されているためリクエストのCookieが表示されませんでした。サイトのAdBlockを無効にした後、警告は消え、開発者ツールは再びクッキーを表示し始めました。
変更を有効にするために、開発ツールを閉じてページを更新することも必要でした。
ブラウザの履歴からキャッシュされたデータを消去しても問題ありません。
これは別の解決策です。
$ ajax（）呼び出しでこの問題が発生した場合は、serverhostが問題を解決する前にhttp://を追加してください。
var requestURL = "http://" + serverHost;
$.ajax({
dataType: "json",
url: requestURL,
data: data,
success: success
});
Asp.Net Mvcアプリケーションを開発していて、コントローラにJsonResultを返そうとしている場合は、JsonメソッドにJsonRequestBehavior.AllowGetを追加してください。それは私のためにそれを修正しました。
public JsonResult GetTaskSubCategories(int id)
{
var subcategs = FindSubCategories(id);
return Json(subcategs, JsonRequestBehavior.AllowGet); //<-- Notice it has two parameters
}