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

307 Temporary RedirectASP.NET MVCのコントローラーからを返すことは可能ですか？

あるフォームから別のURIに送信された値を再送信する必要がある場合があります。POST

JavaScriptを使用してクライアント側で選択を行う（これによりこの問題を回避する）ことはオプションではありません。

投稿されたデータには8kの文字列が含まれているため、 aを介したリダイレクトGETはオプションではありません。これは、一部の（多くの？）ブラウザではURIが長すぎることを意味する可能性があります。

これも可能ですか？

次のケースを検討してください。

• Web サーバーが .NET アプリを実行しています<sessionState cookieless="AutoDetect" />。
• クライアントは、単純なHttpWebRequest(Cookie なし) を使用してデータを送信しています。

この一見単純なケースは、大きな失敗を引き起こします。

.NET は、要求元のエージェント ( ) が Cookie をサポートしているかどうかを判断できないためHttpWebRequest、POST 要求に対して、次のように同じ場所への 302 Found リダイレクトで応答します。

• AspxAutoDetectCookie応答で指定された Cookie
• AspxAutoDetectCookie転送された場所で指定されたクエリ パラメータ

要求元のエージェントは、新しい場所を要求することになってHttpWebRequestいます。.NET は、クエリ文字列を確認すると、これが再要求であることを認識し、指定された Cookieが要求ヘッダーにあるAspxAutoDetectCookieかどうかを確認することで、Cookie がサポートされているかどうかを判断できます。AspxAutoDetectCookie

問題は、ほとんどのリクエスト エージェント (Web ブラウザHttpWebRequest) が 302 Found を 303 See Other であるかのように扱い、元の HTTP メソッドに関係なく、再リクエストを GET にすることです! 最初の POST 要求で送信されたデータは転送されません。

正しい応答は、要求メソッドを変更しない 307 一時リダイレクトである必要があります。(場所 X への POST 要求は、場所 Y へのPOST要求にリダイレクトされます。)

POST 要求が破棄されないように、.NET でこの動作を変更する方法はありますか?

3xx リダイレクトに関する情報

MediaPlayer クラスを使用するアプリがあります... 1.6 および 2.1 デバイスでは常に機能していましたが、2.2 デバイス (およびエミュレーター) でテストして以来、リダイレクトの場合に mp3 ファイルをストリーミングしないことに気付きました最初に行われます...次を返します：

誰かがこの動作に気付いているかどうか疑問に思っていました。もしそうなら、誰かが問題の解決策を持っていますか? それは「AwesomePlayer」かもしれませんが、前任者よりもうまく動作しません:(

送信する特定のメールが開かれているかどうかを追跡しようとしているため、送信するすべてのメールの画像にハッシュURLを使用しています。現在、そのURLが要求されると、電子メールが表示されたという事実をログに記録し（URLのハッシュに基づいて）、Webアプリケーションサーバーからの画像を提供します（すべての人にとって同じ画像です）。

この時点で、1時間に10k以上のリクエストを受け取るのが一般的であるところまで成長しています。クライアントに、より近い画像のURLを使用して3xx HTTP応答を提供することで、クライアントにより良いサービスを提供できると思います。アプリケーションサーバーではなく、専用のCDN。

どのコードが最適ですか？私は302、303、または307のいずれかが利用可能な選択肢だと思います。このメディアにはSEOの価値がなく、私の唯一の関心事は、古いメールクライアントで問題を引き起こすことなく、静的なイメージをクライアントにできるだけ速く配信することです。

http://en.wikipedia.org/wiki/List_of_HTTP_status_codes

私は Netbeans を使用して Web サービス クライアント コード (クライアント スタイルの JAX-WS) を生成するので、Web サービス API を呼び出すことができます。

しかし、Web サービス API を呼び出すと、次の例外が発生します: com.sun.xml.internal.ws.client.ClientTransportException: The server sent HTTP status code 307: Temporary Redirect

なぜ私はこれを得るのですか？回避策は何ですか? 問題は web サービス自体にあるのではないことはわかっています。

これら2つのリダイレクトの違いを理解するのに助けが必要です。

または

HTTPヘッダーの2番目のケースではどうなりますか？デフォルトで設定されているものはありますか、それとも一時的に何かをリダイレクトしたい場合は間違っていますか？

2つ目は間違っていますか、それとも実際の違いはありませんか？「場所」のみを使用した場合、デフォルトで送信されるHTTPヘッダーに関するドキュメントが見つかりません。

前もって感謝します

リダイレクト先が毎日変わる短縮URLサービスを実装しています。URL はモバイル デバイスからアクセスされ、常に GET 要求になります。仕事に最適な 300 タイプのリダイレクトを理解しようとしています。

私の知る限り、ほとんどの URL 短縮サービスは 301 リダイレクトを使用しています (完全に移動されました)。ただし、仕様によると、303 (その他を参照) および 307 (一時的に移動) のリダイレクトは、私たちの場合のために設計されているようです...

• 303/307 は 301 と同様にサポートされていますか? 仕様によると、それらは HTTP 1.1 でのみ実装されたと書かれていますが、それはどのような制限を綴っていますか?
• 301 対 303/307 を選択することで、実際のキャッシングまたはパフォーマンスへの影響はありますか。
• GET リクエストの場合、303 と 307 を選択する理由はありますか?
• 302 リダイレクトを使用する理由はありますか?
• 他に考慮すべきことはありますか？

これは、Using 301/303/307 redirects for dynamic short urlsのフォローアップの質問です。ここでは、宛先 URL が頻繁に変更される場合に短い URL リダイレクトを実装するための最良の方法を決定しようとしています。

301 リダイレクトと 307 リダイレクトはどちらも同じように動作するように見えますが、私に関係する問題は 301 リダイレクトのキャッシングです (ここに文書化されています)。キャッシュ?)、または no-cache ヘッダーを明示的に送信する ("Cache-Control: no-cache, must-revalidate")?

明らかに2010年に、GoogleのMatt Cuttsはインタビューで、インタビュー後のフォローアップメール交換とともに、ドメイン間HTTPステータス301リダイレクトを使用した場合にGoogleがページランクを差し引くことを明らかにしました。つまり、examples.comがあり、HTTPステータス301でexamples.comにリダイレクトするexample.comを購入した場合、Googleは通常そのPRを差し引くことを認めています。

さて、残っているのはHTTPステータス302とHTTPステータス307リダイレクトです。彼らはウィキペディアで、307が新しい方法であり、HTTPステータス302は「ろくでなし」であり、リダイレクトを行う正しい方法ではないと述べています。問題は-IE6以降のほとんどのブラウザはHTTPステータス307をサポートしていますか？ほら、私はもうテストするIE6ブラウザを持っていません。

したがって、問題は、HTTPステータス307リダイレクトの使用を開始する必要がある場合、IE6以降にリリースされたブラウザーとIE6ブラウザーで機能するのでしょうか。

私の CMS には、一時的に非公開で、後で再公開されたページがいくつかあります。それらを処理する最良の方法である SEO の観点から。それらを削除するよう検索エンジンに指示しますか、それとも一時的に移動しますか?

すべてのページが常に再公開されるわけではなく、返されるステータス コードが最適なオプションではない場合もありますが、決して再公開されないページよりも、再公開されるページを適切に処理する方が理にかなっていると思います。なれ。

ユーザーまたは検索エンジンがこのページにアクセスしようとすると、どのステータスが返されますか? 302? 307? 404? または、このシナリオを処理する最良の方法はどれですか?

どうもありがとう