421共有ホストでのリダイレクトされたリクエスト
私は共有ホスト（Apache）を使用していますが、この問題を解決するための支援はほとんど受けていません。メインドメイン https://www.waldorfteacherresources.com があり、2つのcookielessドメインを設定しました：static.waldorfteacherresources.comとstatic.mseifert.com。読み込むと、Firefoxは多くの静的ファイルを421応答で表示します。場合によっては、メインサイトのindex.phpに421エラーが返されます。このエラーは、ブラウザーに直接表示されます。 URLをロードするたびに、421エラーのあるファイルは異なる場合があります。 421の応答が得られない場合があります。
また、奇妙なのは、421応答を持つファイルであっても、とにかくロードするように見えることです：cssファイルがロードされ（そうでない場合、サイトは正しくレンダリングされません）、javascriptファイルがデバッグタブに表示されますFirefoxの。
Comodo SSLを使用しており、PositiveSSLマルチドメイン証明書を持っています。 ISPから受け取る応答は
これを確認すると、主な問題は、サイトコードがサーバーを混乱させるような方法で機能していることです。
何らかの理由で、サイトはそれ自体にリクエストを行い、Hostヘッダーをwww.waldorfteacherresources.comとして提示しているのに、実際にはstatic.waldorfteacherresources.comにアクセスしているように見えます。
421 Errors here の説明を読みましたが、これは何らかの理由でコードが問題を引き起こしているのか、ISP側に変更可能なものがあるのかを判断するのに役立ちません新しいISPを見つける必要があります）。共有ホストであるため、サーバー構成は変更されません。
以下は、同じURLを2回ロードした場合のFirefoxのネットワークタブです。任意の助けをいただければ幸いです。
ブラウザが別のサイトの接続を再利用しようとすると、421が返されます。これはHTTP/2で許可され、別の接続を開くコストを節約します。ほとんどの場合、HTTP/2で使用する接続は少ない方がよいためです。
ブラウザは、同じIPアドレスにマップし、使用する証明書が両方のサイトをカバーする接続のみを再使用する必要があります（3つのサイトの場合）。
これらの条件にもかかわらず、ときどきブラウザーは接続すべきでないときに接続を再利用しようとすることがあります。 Apacheの主なケースは、vhostごとに異なるSSL/TLS設定がセットアップされている場合です。 3つのドメインのそれぞれについてssllabs.comを見ると、セットアップは同じように見えるため、Apacheがこれを返す理由を確認するのは困難です。ホスティング提供者に連絡して、これを確認するよう依頼する必要があります。
これらの場合、Firefoxは421応答を確認し、新しい接続を確立して、リソースを再度要求します。ただし、301や302とは異なり、開発者ツールでは個別のリクエストとして表示されないようです。
これを修正する代替手段は次のとおりです。
- ホスティングプロバイダーに原因を特定させ、接続を再利用できるようにします。
- ドメインごとに異なる証明書を使用します（したがって、ブラウザーは接続を再利用しようとしません）。
- 同じサーバーにマッピングされている場合でも、他のドメインには異なるIPアドレスを使用します（したがって、ブラウザーは接続を再利用しようとしません）。
- Http/2の使用を停止します-通常はパフォーマンスが向上するため、これは恥ずべきことです。
- 少なくともHTTP/2では、他のドメインの使用を停止してください。
最後の1つを真剣に見るべきだと思います。他のドメイン（シャーディングと呼ばれる）を使用する利点は、HTTP/1についての私の意見ではしばしば誇張されており、HTTP/2では必要ないはずです。
シャーディングは2つの理由で行われます。
- HTTP/1.1でさらに6つの接続を許可するには、ブラウザは通常、ドメインごとに6つの同時接続で最大になります。ただし、これらの7番目、8番目...などの接続が頻繁に使用されない限り、それらを設定するコストは価値がない場合があります。また、HTTP/2の場合、制限ははるかに高くなります（通常、接続ごとに少なくとも100の同時ストリーム）。
- リクエストサイズを節約するためのCookieのないドメイン。しかし、HTTP/2では、HTTPヘッダーが圧縮されているため、これについて心配する必要はありません（これもまた私の意見では、この値は誇張されていました-Cookieの実際の大きさです）。
ホームページのwebpagetest を見ると、wwwドメインにメインページをロードし、次に1つの静的サブドメインに6個のアセットを、次のサブドメインに6個のアセットをロードし、それぞれにさらに数個を追加しています：
接続とSSLネゴシエーションでほぼすべての接続を再確立する必要があるため、421の真のコストを確認できます。これを少し無視すると、2つの静的サブドメインで同時に6つ以上のリソースをダウンロードしていることがわかります。したがって、これがHTTP/1.1接続である場合、6つの接続制限を少し破ることでメリットが得られます。ただし、最初の要求後にアイドル状態になっているwww接続も無駄にしています。これは、接続ビューからより明確になります。
そのため、これらのサブドメインの1つを取り除き、wwwドメインのアセットを提供して、その最初の接続から利用率を引き出すことができます。
HTTP/2の場合、必要のない他のドメインも削除できます。その後、HTTP/2とHTTP/1.1のユーザーに異なる結果を提供できますが、それは複雑です すべてのメインブラウザーがHTTP/2をサポートします であり、合計24のリクエストに対して、あまり多くはなりませんそうでない場合は、1つのドメインにパフォーマンスドラッグがかかります。
要するに、ホームページのクイックルックからとにかくパフォーマンスを向上させることはできず、この421問題に当たっている間、それをかなり妨げているという本当の正当な理由がない限り、クッキーレスドメインへのシャーディングを停止します。