URLハッシュがリダイレクト間で保持されている
何らかの理由で、非IEブラウザーは、サーバー側のリダイレクトが（Locationヘッダーを使用して）送信されたときにURLハッシュ（存在する場合）を保持しているようです。例：
// a simple redirect using Response.Redirect("http://www.yahoo.com");
Text.aspx
私が訪問した場合：
Test.aspx#foo
Firefox/Chromeでは、次のことになります。
http://www.yahoo.com#foo
なぜこれが起こるのか誰かが説明できますか？さまざまなプラットフォームでさまざまなサーバー側リダイレクトを使用してこれを試しましたが（すべて、Locationヘッダーになります）、これは常に発生するようです。 HTTP仕様のどこにも見当たりませんが、ブラウザ自体に問題があるようです。 URLハッシュ（予想どおり）がサーバーに送信されることはないため、サーバーリダイレクトがサーバーに汚染されることはなく、ブラウザーは何らかの理由でURLハッシュを保持しているだけです。
何か案は？
これが正しい動作であることをお勧めします。 302および307ステータスコードは、リソースが他の場所にあることを示します。 #bookmarkはリソース内の場所です。
リソース（htmlドキュメント）が見つかると、ブラウザはドキュメント内の#bookmarkを見つけます。
例えは次のとおりです。第57章の本で何かを調べたいので、図書館に行って本を入手します。しかし、棚には本が移動したというメモがあり、現在は別の建物にあります。だからあなたは新しい場所に行きます。あなたはまだ第57章が欲しいです-それはあなたが本をどこで手に入れたのかは無関係です。
これは、以前のHTTP仕様ではカバーされていなかった側面ですが、 後のHTTP開発で対処されています ：
サーバーが300（「複数選択」）、301（「永続的に移動」）、302（「一時的に移動」）、または303（「他を参照」）の応答コードを返し、サーバーが1つ以上のURIも返す場合リソースが見つかる場所では、クライアントは、元のURIのフラグメント識別子が最後に追加されたかのように新しいURIを処理する必要があります。
例外は、返されたURIにすでにフラグメント識別子がある場合です。その場合、元のフラグメント識別子を追加してはなりません。
したがって、元のURIのフラグメントも、フラグメントが含まれていない限り、リダイレクトURIにも使用する必要があります。
これは2000年に期限切れになったドラフトにすぎませんが、上記の動作は、今日のWebブラウザのデファクトスタンダードの動作のようです。
@ Julian Reschke または @ Mark Nottingham おそらくこれについてもっと/よく知っています。
私が見つけたものから、正確な振る舞いがどうあるべきかは明らかではないようです。これに問題を抱えている人はたくさんいます。リダイレクトを通じてブックマークを保持したい人もいれば、それを取り除きたい人もいます。
ブラウザが異なればこれの処理も異なるため、実際にはどちらの動作にも依存することは役に立ちません。
それは間違いなくブラウザの問題です。ブラウザがURLのブックマーク部分をサーバーに送信することはないため、ブックマークがあるかどうかをサーバーが確認するためにできることはなく、ブックマークについて確実に行うこともできません。