WebSurfer's Home

Filter by APML

CORS 非対応の場合のエラーメッセージ(その2)

by WebSurfer 4. June 2024 12:47

先の記事「CORS 非対応の場合のエラーメッセージ」の続きで、fetch メソッドで指定した URL が間違っていた場合どうなるかを調べたので、備忘録として書いておきます。

URL が間違っているとサーバーからは HTTP 404 Not Found 応答が返ってきますが、それがどのように表示されるかが書いておきたかったことです。

ちなみに、404 応答というのは、(1) URL のホスト名は正しく名前解決されブラウザからの要求は Web サーバーに届いた、(2) 要求を受け取った Web サーバーは URL に指定されたリソースを探したが見つからなかった、(3) Web サーバーは見つからなかったという応答を返した・・・ということです。

検証に使ったのは、先の記事「Web API に CORS 実装 (CORE)」に書いた ASP.NET Core Web API アプリで、Web API の CORS を無効にして、ドメインが異なる MVC アプリから fetch API を使って Web API に要求を出します。その際、正しい URL は https://localhost:44371/api/values とすべきところを、values ⇒ valuesx としました。

実は、CORS を無効にしたら 404 応答は返ってこないと思い違いをしていたのですが、そうではなかったです。バックエンドが CORS 非対応でもフロントエンドから要求は出て、URL が間違っているため指定されたリソースが見つからない場合は 404 応答が返ってきます。

以下に、「CORS 非対応 URL 誤」「CORS 非対応 URL 正」「CORS 有効 URL 誤」の 3 つのケースで、Chrome のディベロッパーツールの Console に表示されるエラーメッセージと、Fiddler で要求・応答をキャプチャした画像を貼っておきます。

(1) CORS 非対応 URL 誤

CORS 非対応でもブラウザから要求は出ます。URL が間違っているので Web サーバーは 404 応答を返します。それを受けたブラウザでは、まず応答ヘッダに Access-Control-Allow-Origin が無いということで CORS 関係のエラーメッセージを出しています。次に、404 応答なのでそのエラーメッセージ、最後に Failed to fetch (fetch 失敗) というエラーメッセージを出しています。

CORS 非対応 URL 誤

Fiddler の画像です。404 応答が返ってきています。バックエンドが CORS 非対応なので応答ヘッダには Access-Control-Allow-Origin は含まれていません。

CORS 非対応 URL 誤


(2) CORS 非対応 URL 正

上の (1) のケースから URL を正しいものにした場合の結果です。URL は正しいので当然 404 応答ではなく 200 応答が返ってきます。JSON 文字列も正しく応答コンテンツに含まれて返ってきます。しかし、応答ヘッダに Access-Control-Allow-Origin が無いので fetch メソッドでのデータの取得に失敗しています。

CORS 非対応 URL 正

Fiddler の画像です。URL は正しいので 200 応答が返ってきています。応答の TextView (コンテンツ) を見ると期待通り JSON 文字列が返ってきています。しかし、バックエンドが CORS 非対応なので応答ヘッダには Access-Control-Allow-Origin は含まれていません。

CORS 非対応 URL 正


(3) CORS 有効 URL 誤

上の (1) のケースからバックエンドの CORS 対応を有効にした結果です。URL は間違ったままなので 404 応答が返ってきています。上の (1), (2) と違って fetch 失敗とはみなされないようです。

CORS 有効 URL 誤

CORS を有効にしたので応答ヘッダには Access-Control-Allow-Origin が含まれています。

CORS 有効 URL 誤

Chrome のディベロッパーツールの Source タブの画面です。上の (1), (2) のケースでは fetch(url) の実行で例外がスローされて処理が終わってしまいますが、(3) のケースでは if(response.ok) 以降に処理が進みます。

CORS 有効 URL 誤

Tags: , , , ,

JavaScript

WebResource.axd の HTTP 404 エラー

by WebSurfer 26. January 2013 17:09

WebResource.axd の HTTP 404 エラーのトラブルシューティングにつきいろいろ調べたので、今後役に立つかもしれない情報を備忘録として書いておきます。

まず、トラブルシューティングの情報で、ググって探した中でよさそうだと思ったページを以下に書いておきます。

Troubleshooting WebResource.axd

Web Resources Troubleshooting

前者のページでは、以下の事項がエラーの原因として挙げられています。自分もそう思います。

  1. Missing compression exclusion
  2. Slight error with compression module
  3. Missing MachineKey / ValidationKey
  4. Bad IIS setup, specifically the Application extension mapping

ただし、MSDN フォーラムで、.Net Framework 4 関連のアップデートを、すべてアンインストールしてから 再インストールしたら問題が解決したという話がありましたので、Windows Update の失敗(結果として MachineKey の設定が壊れる?)も原因として考えた方がよさそうです。

上記の 4 に関連して、"Verify that file exists" のチェックを外すよう、上に紹介したページに書かれています。その理由は、チェックを入れると iis は事前にファイルシステムに当該ファイルが存在するか確認するが、WebResource.axd というファイルはファイルシステムに存在しないのでエラーになる(結果 HTTP 404 を返す)ということだそうです。そのことは以下のページに詳しく書いてあります。

The Verify That File Exists Setting

なお、上記は iis6 の場合で、iis7 には "Verify that file exists" というチェックボックスは無いです。それに代わるものは以下のページを見てください。

Tip / Trick: how to turn off "verify file exists" in IIS7

iis7 マネージャーのハンドラマッピングの設定で、[要求のマップ先が次の場合のみハンドラを呼び出す(I)]にチェックを入れて、[ファイル(F)]を選択することが、iis6 で "Verify that file exists" にチェックを入れるのと同じことになるそうです。なので、下の画像のようにチェックを外す(resourceType="Unspecified" に設定する)必要があります。

HTTP ハンドラの設定

ただ、デフォルトで間違いなく設定される(チェックは外れている)はずなので、自分でいじったりしなければ、これが 404 エラーの原因とは考えにくいですが。

404 エラーを返すのが特定の WebResource.axd のみの場合、その WebResource.axd に指定されているリソース(ファイル)を特定したい場合があると思います。

WebResource.axd のクエリ文字列のパラメータ d には、HTTP ハンドラが取得すべきファイルが指定されています。しかし、パラメータ d は暗号化されているため、そのまま見てもどのファイルを取得しようとしているかは分かりません。

パラメータ d の詳細については MSDN マガジンの ASP.NET AJAX アプリケーションの国際化 の「動作のしくみ」のセクションを見てください。

このページに "System.Web.UI.Page クラスの内部静的メソッド DecryptString および EncryptString を使用して、ページでこれらの文字列を暗号化および復号化できます" と書いてありますが、自分が調べた限りでは、Page クラスにはそのようなメソッドは公開されていません。

WebResource.axd のパラメータ d の値を復号する方法は、以下のページが参考になると思います。

Debugging ASP.NET 2.0 Web Resources:Decrypting the URL and Getting the Resource Name

そのページの下の方に "I am attaching a standalone page that you can drop in your application’s root and request it." とありますが、その a standalone page をクリックすると WebResources.aspx というソースファイルを入手できます。

入手できたら WebResources.aspx を問題の起こっている Web アプリケーションのルート直下に配置して使ってみてください。当方で検証した限りでは問題なく復号できました。

Tags: ,

ASP.NET

About this blog

2010年5月にこのブログを立ち上げました。主に ASP.NET Web アプリ関係の記事です。ブログ2はそれ以外の日々の出来事などのトピックスになっています。

Calendar

<<  February 2025  >>
MoTuWeThFrSaSu
272829303112
3456789
10111213141516
17181920212223
242526272812
3456789

View posts in large calendar