38

何らかの理由で、非 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 ハッシュ (予想どおり) はサーバーに送信されないため、サーバーのリダイレクトはそれによって汚染されず、ブラウザーは何らかの理由でそれを保持しているだけです。

何か案は？

4

3 に答える 3

75

これが正しい動作であることをお勧めします。302 および 307 ステータス コードは、リソースが別の場所にあることを示します。#bookmarkリソース内の場所です。

リソース (html ドキュメント) が見つかったら、ブラウザ#bookmarkはドキュメント内で を見つけます。

類推は次のとおりです。57 章の本で何かを調べたいので、図書館に行ってその本を入手します。しかし、本が移動したというメモが棚にあり、現在は別の建物にあります。それで、あなたは新しい場所に行きます。あなたはまだ第57章を望んでいます-あなたが本をどこで手に入れたかは関係ありません.

于 2011-03-12T15:47:31.683 に答える
28

これは、以前の HTTP 仕様ではカバーされていませんでしたが、後の HTTP 開発で対処された側面です。

サーバーが 300 (「複数選択」)、301 (「完全に移動」)、302 (「一時的に移動」)、または 303 (「他を参照」) の応答コードを返す場合、およびサーバーが 1 つ以上の URI も返す場合リソースが見つかる場合、クライアントは新しい URI を、元の URI のフラグメント識別子が最後に追加されたかのように扱う必要があります (SHOULD)。

例外は、返された URI に既にフラグメント識別子がある場合です。その場合、元のフラグメント識別子を追加してはなりません。

したがって、フラグメントも含まれていない限り、元の URI のフラグメントもリダイレクト URI に使用する必要があります。

これは 2000 年に有効期限が切れたドラフトにすぎませんが、上記のような動作は、今日の Web ブラウザーの事実上の標準的な動作のようです。

@Julian Reschkeまたは@Mark Nottinghamは、おそらくこれについてもっと/よく知っています。

于 2011-03-12T16:23:39.883 に答える
2

私が見つけたものから、正確な振る舞いがどうあるべきかは明らかではないようです。これに問題を抱えている人はたくさんいます。リダイレクトを介してブックマークを保持したい人もいれば、それを取り除きたい人もいます。

ブラウザが異なればこれも異なる方法で処理されるため、実際にはどちらの動作にも依存することは役に立ちません。

それは間違いなくブラウザの問題です。ブラウザがURLのブックマーク部分をサーバーに送信することはないため、ブックマークがあるかどうかをサーバーが確認することはできず、ブックマークについて確実に実行できることもありません。

于 2011-03-12T15:59:16.857 に答える