Xyzウェブマスターを使用してサイトに本番環境を展開しています。以下は、2つの異なるインスタンスでエラーが発生した場合のWebコンソールの2つのスクリーンショットです。
私たちはこの問題に断続的に直面しており、常にではありません。さらに、これは少数のユーザーで発生しており、すべてのユーザーではありません(これが地域に関連しているかどうかはわかりません)。この問題が発生すると、ページが正しく読み込まれません。数回の更新試行の後、ページは適切にロードされ、その他はすべて期待どおりに機能します。
Webマスターが厳密なMIMEタイプチェックを有効にしたことは既知の事実です。
すべてのリソース(.jsおよび.cssファイル)のURLパスは正確です。これらのファイルのOriginで設定されたMIMEタイプは正しいです。以下は、これらのファイルが参照される.jspページのコードスニペットです。
<link rel="stylesheet" href="${pageContext.request.contextPath}/static/css/bootstrap/bootstrap.min.css" type="text/css" />
<link rel="stylesheet" type="text/css" href="${pageContext.request.contextPath}/static/css/jquery/jquery-ui.css" type="text/css" />
<script src="${pageContext.request.contextPath}/static/js/jquery/jquery.min.js" type="text/javascript" ></script>
<script src="${pageContext.request.contextPath}/static/js/bootstrap/bootstrap.min.js" type="text/javascript"></script>
<script src="${pageContext.request.contextPath}/static/js/jquery/jquery.slimscroll.min.js" type="text/javascript"></script>
<script src="${pageContext.request.contextPath}/static/js/jquery/jquery.dataTables.min.js" type="text/javascript"> </script>
私の理解によると、要求フローはこの小さな図のように機能します。
クライアントブラウザー(ステップ4)に応答を送信しているときに、問題がウェブマスターサーバーによって引き起こされていると思います。彼らがAppサーバーからの応答を読んだ後、私は彼らのサーバーがファイル(.css/.js)の同じContent-Typeを維持することに失敗していると思います。これを主張する前に、私は私の理解を確認したいと思いますが、それは生産でのみ起こっているので、これを証明するためのツールには不十分です。デバッグする開発環境では、この問題は発生しません!!!
ウェブマスターによると、問題はアプリケーションのコードにあります。コードで確認できるのは、.jspファイル内の各.js/.cssファイルのタイプです。私が見ているのは、ブラウザがウェブマスターからの応答を受け入れていないということです。私たちは rel = "stylesheet" type = "text/css" for CSS files と type =を維持しているのですべてのjavascriptファイルの「text/javascript」、アプリケーションサーバーで問題が発生しません!!
アドバイスをよろしくお願いします。
編集1:以下のように、web.xmlにMIMEタイプを追加しました。
<mime-mapping>
<extension>js</extension>
<mime-type>application/javascript</mime-type>
</mime-mapping>
<mime-mapping>
<extension>css</extension>
<mime-type>text/css</mime-type>
</mime-mapping>
参照用に以下のように、リバティサーバーのserver.xmlにmimetypesを追加しました。
<mimeTypes>
<type>js=application/javascript</type>
<type>css=text/css</type>
</mimeTypes>
これにもかかわらず、ブラウザでMIMEタイプの不一致が頻繁に発生します。ウェブマスターチームは、アプリケーションサーバーは妥当な情報なしに間違ったコンテンツを送信している必要があると主張しています。
編集2:次に、以下のコマンドを使用して、リソース(js/cssファイル)が送信するヘッダーをテストしました。
curl -I https://myapplication/static/js/angular/angular.min.js 以下は私が受け取る応答です。ループを100回実行すると、常に同じ応答が返されます。
HTTP/1.1 200 OK X-Backside-Transport: OK OK Content-Language: en-US Content-Length: 168517 **Content-Type: application/javascript** Date: Tue, 19 Jun 2018 10:38:25 GMT Last-Modified: Tue, 29 May 2018 17:04:10 GMT X-Powered-By: Servlet/3.1 X-Global-Transaction-ID: 1178221711 Connection: close
そのため、アプリケーションサーバー側で問題は発生しません。
-編集3:古いキャッシュがこの種の問題を引き起こす可能性があるとWebマスターが提案した場合、キャッシュは側から無効にされます。キャッシュが無効になっていることを確認するために、サーバー側のコードも追加で作成しました。以下は参照用のコードスニペットです。
response.setHeader("Cache-Control", "no-cache, no-store, must-revalidate"); // HTTP 1.1.
response.setHeader("Pragma", "no-cache"); // HTTP 1.0.
response.setHeader("Expires", "0"); // Proxies.
リソースがキャッシュからではなくサーバーから読み込まれることを確認するには、開発者ツールのネットワークタブを確認します。リソースが200のステータスコードを示している場合、サーバーから正常に読み込まれます。ステータスコードが304の場合、キャッシュからロードされます。
-Edit 4:ウェブマスターがssl接続を確立する方法を知りません。 SSL接続が適切に確立されていない場合、コンテンツはtext/htmlとして提供されます。この段階では、それが事実かどうかはわかりません。私は問題を解決するためにすべての可能な領域を探しています!!!
この問題を取り除くために見つけた唯一の方法は、スタイルとスクリプトファイルをjspファイル内にインライン化することです。
各cssファイルと.jsファイルを縮小し、jspファイルにインラインで追加しました。
これで問題が解決しました!!
リクエストを開始するクライアントがリクエストするもの(HTML/XML)は、一般にほとんど無意味であり、setting別のファイルリクエストのmimeには望みがありません。 サーバーの応答は、最終的にMIMEタイプの応答を決定します。これを行うには、一般的に2つの方法があります。
ほとんどの場合、Apache HTTPサーバーでは、同じ拡張子を持つすべてのファイルが同じMIMEタイプを持っているため、例ではすべての* .jsファイルがapplication/javascript
MIMEタイプを持っています。
Apache .htaccess
ファイルによるMIMEタイプの設定:
AddType text/css .css
AddType application/javascript .js
場合によっては、Apacheリライトやその他の高度な方法を使用することもあり、ファイル拡張子がない場合もあります。 MIMEタイプは個別にファイルに追加できます。
PHPを介してMIMEタイプを設定する:
header('Content-Type: text/css; charset=UTF-8');//Use only in .css files.
header('Content-Type: application/javascript; charset=UTF-8');//Use only in .js files.
何らかの理由で.css
ファイル内でPHPを実行する必要がある場合は、これを.htaccess
ファイルで使用し、上記のコードを使用してファイルのヘッダーは、ブラウザに正しいMIMEタイプが何であるかを伝えます。
AddType application/x-httpd-php5 .css .html
断続的な問題の原因については、この問題やその他の発生している問題を回避するための明確な目的で、独自のコードのallを記述しているため、わかりません。もちろん、ほとんどの人はそのオプションを持っていません。したがって、問題の原因を突き止める際に推奨できる最良のシナリオは、ファイルのヘッダーを設定しているもの(HTMLとして提供されているCSSファイルなど)を特定することです。 PHPこれらのファイルで実行されている)などのサーバーコードがある場合は、それをオーバーライドする必要があります(たとえば、上記のPHP)を使用して)。 criticalヘッダーを理解する最初に送信する必要がありますコンテンツが送信される前に送信しないと、ヘッダーが表示されなくなり、ファイルリクエストが破損する可能性があります。サーバー側のコードが含まれている可能性があると問題があります。それがnotの場合、設計により、FTP経由でダウンロードし、直接確認して、ライブサーバー上のものが開発マシン上のものと一致することを確認することをお勧めします(例えば、それらのファイルはハッキングされましたか)。
さらに、投稿したXMLは、サーバーから要求されたものには影響を与えません(これが、Amazonのサーバーによって正式にサポートされているとどこかで述べられていない限り)。