問題タブ [http-status-code-307]

RESTful Webサービスでは、 HTTP 303を使用して、クライアントをリソースの正規表現にリダイレクトすることを推奨しています。

この本によると、HTTP 302は303（「その他を参照」）と307（「一時的なリダイレクト」）に置き換えられました。HTTP 301（「永続的なリダイレクト」）もあります。クライアントはHTTP301および307をキャッシュできますが、303はキャッシュできません。

これに照らして、どのステータスコードが適切な正規化ですか？なぜ本は307よりもHTTP303の使用を提唱しているのですか？結局のところ、後者はキャッシュ可能です。

HTTP 303は他の HTTP メソッドで受け入れられますか? HTTP 303を他の HTTP メソッドに使用できることを確認しました。

Post/Redirect/Getパターンでは、サーバーが を返す前に操作を実行する必要がありますHTTP 303。HTTP PUTこれとDELETE他のタイプのリダイレクトについても同じことが言えますか? サーバーは、リダイレクトの前に操作を実行する必要がありますか? それとも、クライアントが必要に応じて正規の URL でリクエストを繰り返すと想定できますか?

これは、リダイレクトが負荷分散によく使用されるという事実を考慮すると、さらに興味深いものになります。

301 リダイレクトと 307 リダイレクトの違いについて疑問に思っています。

自作の URL リダイレクタを介してバックリンクを生成しようとしています。「リンク ジュース」または「ページ ランク ジュース」のいずれかが、元のバック ページから最終 URL に直接流れることを望んでいますが、元のバックページがうまくいかない場合、その特定のページのリダイレクト リンクを削除して、そのリンクを遮断できるようにしたいと考えています。わかる？

私の理解では、301 は永続的なものであり、Google は 301 を認識し、キャッシュされた URL を最終的な宛先として更新します。後でそのリダイレクトを終了するかどうかに関係ありません。

307 を使用すると、リンク先 URL がキャッシュされず、リダイレクト URL をチェックして、バック リンクが実際に指している場所を確認し続けます。リダイレクト リンクを無効にすると、Google はそのバック リンクを宛先 URL。

これは正しい要約ですか？

UrlRewriterを使用してリダイレクトを実行するルールを作成しました。

301 Moved Permanantly問題は、リダイレクトを発行していることです。

リダイレクトを「一時的な」リダイレクトとしてマークできます。

その場合、302 Foundリダイレクトが誤って発行されます。

問題は、これらのリダイレクトの両方が間違ったリダイレクトであるということです。次を発行するには UrlRewriter が必要です。

どうやってやるの？

注: を発行するために必要な307理由は、307(および303) が発明された理由です。すべてのブラウザーが302正しく処理されません。をに変換POSTしGETます。別の場所に投稿する必要があることを User-Agent に伝える必要があります。

クライアントは正しい場所へのリダイレクトを発行します。

私のサイトでは、ユーザーが最初にアクセスしたときにセッショントークンが割り当てられていない場合、307 によってトークンが適用されているサブドメインにリダイレクトされ、現在表示されていたページに戻されます。これは、複数のドメインと CName にわたる SSO に対して行われます。

しかし、307 には、ソーシャル共有ボタン (Facebook、Twitter、Google Plus) が関係している場合に問題があります。リダイレクトが呼び出されますが、ソーシャル サイトは SSO サブドメインを決して離れないように見えます。

この問題を解決するにはいくつかの方法があることを認識しているので、私の質問は次のとおりです。

1. Facebook/Twitter/GooglePlus のリクエスト ドメインは何ですか?ロジックを使用して sso ドメインにリダイレクトされないようにすることができますか?

2. ソーシャル サイトが 307 リダイレクトに従っていないのはなぜですか?

3. ソーシャル サイトに Cookie やセッションを関連付けることはできますか?