149

URLフラグメント（の後ろの部分）がサーバーに送信されないことはよく知られて#います。

Location:サーバーリダイレクト（HTTPステータス302とヘッダー経由）が関係している場合、フラグメントはどのように機能するのでしょうか。

私の質問は本当に2つあります：

  1. 元のURLにフラグメント（/original.php#foo）があり、リダイレクトが行われた場合、元のURL/new.phpのフラグメント部分は単に失われますか？それとも、新しいURLに適用されることがありますか？
    この場合、新しいURLは使用さ/new.php#fooれますか？

  2. 元のURLに関係なく、サーバーがフラグメント（/new.php#foo）を含む新しいURLにリダイレクトすると、フラグメントは「名誉を与えられ」ますか？または、サーバーは実際にはフラグメントに干渉するビジネスをまったく持っていません-したがって、ブラウザは単に行くだけでそれを無視します/new.phpか？

4

4 に答える 4

146

2014 年 6 月 27 日更新:

RFC 7231、Hypertext Transfer Protocol (HTTP/1.1): Semantics and Contentは、PROPOSED STANDARD として公開されています。変更ログから:

Location ヘッダー フィールドの構文が変更され、相対参照やフラグメントを含むすべての URI 参照が許可されるようになりました。(セクション 7.1.2)

セクション 7.1.2の重要なポイント。場所:

3xx (リダイレクト) 応答で提供される Location 値にフラグメント コンポーネントがない場合、ユーザー エージェントは、値がリクエスト ターゲットの生成に使用される URI 参照のフラグメント コンポーネントを継承するかのようにリダイレクトを処理する必要があります (つまり、リダイレクトは元の参照のフラグメントがある場合)。

たとえば、URI 参照「http://www.example.org/~tim」に対して生成された GET 要求は、ヘッダー フィールドを含む 303 (See Other) 応答になる可能性があります。

Location: /People.html#tim

これは、ユーザー エージェントが「http://www.example.org/People.html#tim」にリダイレクトすることを示唆しています。

同様に、URI 参照「http://www.example.org/index.html#larry」に対して生成された GET 要求は、ヘッダー フィールドを含む 301 (Moved Permanently) 応答になる可能性があります。

Location: http://www.example.net/index.html

これは、元のフラグメント ID を保持して、ユーザー エージェントが「http://www.example.net/index.html#larry」にリダイレクトすることを示唆しています。

これはあなたの質問に明確に答えるはずです。

更新終了

これは、現在の HTTP 仕様に関する未解決の (特定されていない) 問題です。これは、 IETF httpbis ワーキング グループの 2 つの問題で取り上げられています。

#6 は、Locationヘッダー内のフラグメントを許可します。#43 こう言っています。

これをさまざまなブラウザでテストしました。

  • Firefox と Safari は、ロケーション ヘッダーでフラグメントを使用します。
  • Opera は、存在する場合はソース URI のフラグメントを使用し、存在しない場合はリダイレクト先のフラグメントを使用します
  • IE (8) はロケーション URI のフラグメントを無視するため、存在する場合はソース URI のフラグメントを使用します。

提案：

「注: 元の URI のフラグメント識別子とリダイレクトを組み合わせる必要がある場合の動作は定義されていません。現在のユーザー エージェントは実際にどのフラグメントが優先されるかが異なります。」

[...]

IE8はフラグメント識別子 from を使用しているようですLocation(私が見た動作は localhost に限定されている可能性があります)。

したがって、元の URI が何であれ、Location ヘッダーのフラグメントが使用されるという点で、Safari/IE/Firefox/Chrome (テスト済み) で一貫した動作をしているようです。

したがって、私は提案を変更して、それを期待される動作として文書化します。

これにより、ブラウザとの互換性が最も高く、将来的に保証されます (この問題は最終的に標準化されるため)、質問に対する回答:

A:元の URL のフラグメントは破棄されます。

B:Locationヘッダーからのフラグメントが受け入れられます。

于 2010-02-21T12:57:31.013 に答える
46

Safari 5 および IE9 以下では、HTTP/3xx リダイレクトが発生すると、元の URI のフラグメントがドロップされます。応答の Location ヘッダーでフラグメントが指定されている場合は、それが使用されます。

IE10 以降、Chrome 11 以降、Firefox 4 以降、および Opera はすべて、3xx リダイレクトの後、元の URI のフラグメントを「再接続」します。

テストページ: http://www.webdbg.com/test/redir/fragment/ .

この問題の詳細については、http://blogs.msdn.com/b/ieinternals/archive/2011/05/17/url-fragments-and-redirects-anchor-hash-missing.aspxを参照してください。

于 2011-05-06T18:11:28.590 に答える
12

お知らせするために、ここで適切な仕様を見つけることができます。すべての動作方法を定義する w3c による: http://www.w3.org/TR/cuap#uri - 条項 4.1 - 以下を参照:

リソース (URI1) が移動した場合、HTTP リダイレクトはその新しい場所 (URI2) を示すことができます。

URI1 にフラグメント識別子 #frag がある場合、ユーザー エージェントが到達しようとする新しいターゲットは URI2#frag になります。URI2 にすでにフラグメント識別子がある場合、#frag を追加してはならず、新しいターゲットは URI2 になります。

間違い: 現在のほとんどのユーザー エージェントは HTTP リダイレクトを実装していますが、フラグメント識別子を新しい URI に追加していません。これは、最終的に間違ったリソースになるため、一般的にユーザーを混乱させます。

参考文献:

HTTP リダイレクトは、HTTP/1.1 仕様 [RFC2616] のセクション 10.3 で説明されています。必要な動作については、「リダイレクトされた URL でのフラグメント識別子の処理」[RURL] で詳しく説明されています。「Persistent Uniform Resource Locator (PURL)」という用語は、HTTP リダイレクトを介して別の URL を指す URL (URI の特殊なケース) を示します。詳細については、「Persistent Uniform Resource Locators」[PURL] を参照してください。例：

ユーザーがhttp://www.w3.org/TR/WD-ruby/#changesでリソースを要求し 、サーバーがユーザー エージェントをhttp://www.w3.org/TR/ruby/にリダイレクトするとします。後者の URI を取得する前に、ブラウザはフラグメント識別子 #changes を追加する必要があります: http://www.w3.org/TR/ruby/#changes。

于 2012-07-01T17:23:11.597 に答える
0

私が直面している解決策で同様の問題を投稿してください。

preserving hash in IE302リダイレクトの同様の要件を持つ誰かに役立つことを願っています.

リンクだけではなく、回答の重要な部分を追加する

SiteMinderアプリケーションで認証を使用します。

認証SiteMinderが302 redirection成功しvalueた/myapp/後、. 以下のサンプルフォームwithout hash fragmentredirect

サンプルログインフォーム

redirect非表示の変数の値にはハッシュ フラグメントが含まれておらず、それ/myapp/は 302 リダイレクトであるため、ハッシュ フラグメントは、アプリケーションに到達する前であっても IE によって自動的に削除され、アプリケーション コードで試しているソリューションがうまくいきません。

IE はのみにリダイレクトして/myapp/おり、アプリのデフォルトのホームページに着陸していますhttps://ourapp.com/myapp/#/home。

この動作を理解するのにほぼ 1 日を費やしました。

解決策は次のとおりです。

ログイン フォームの隠し変数 ( redirect)の値を変更しwindow.location.hashて、既存の値に追加することでハッシュ フラグメントを保持します。以下のコードに似ています

$(function () {
  var $redirect = $('input[name="redirect"]');
  $redirect.val($redirect.val() + window.location.hash);
});

この変更後、redirect隠し変数はユーザーが要求した URL 値を として保存し、IE/myapp/#/pending/requestsにSiteMinderリダイレクトします。/myapp/#/pending/requests

上記のソリューションは、3 つのブラウザすべてで正常に機能していますChrome, Firefox and IE。

詳細な説明とこの問題の解決策を提供してくれた @AlexFord に感謝します。

于 2020-07-15T14:49:27.617 に答える