新しい API でいくつかのテストを行った後、これを発見しました。その側の管理者は、自分の側で POST を実行している間に GET を実行していると言いました。デバッグを有効にした後、リクエストが最初の POST を実行してから、新しい 302 URL で GET を実行することがわかりました。
問題の内容を理解した後、問題は修正されましたが、これはバグですか、それとも予期された動作ですか? POST で 302 を受け取った場合は、例外を発生させないか、新しい URL への POST を再試行してください。
バグであることが確実でない限り、GitHub にバグとして記録したくありません。これについての意見が欲しいだけです。
ありがとう
RFCによると、
GET または HEAD 以外のリクエストに応答して 302 ステータス コードを受信した場合、ユーザーが確認できない限り、ユーザー エージェントはリクエストを自動的にリダイレクトしてはなりません。これにより、リクエストが発行された条件が変更される可能性があるためです。
( http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.3 )
したがって、この動作は少なくとも準拠していません-ただし、RFC には次のようにも記載されています。
注: RFC 1945 および RFC 2068 では、リダイレクトされた要求でクライアントがメソッドを変更することは許可されていないと規定されています。ただし、ほとんどの既存のユーザー エージェント実装は、302 を 303 応答であるかのように扱い、元の要求メソッドに関係なく、Location フィールド値に対して GET を実行します。ステータス コード 303 および 307 は、クライアントに期待される反応の種類を明確に明らかにしたいサーバー用に追加されました。
IOW: RFC に準拠していませんが、これはほとんどのユーザー エージェントのデフォルトの動作であり、ほとんどの Web アプリは実際に 303 ではなく 302 を使用して post-redirect-get を実装しています。
したがってrequests、ここでの動作は明らかにバグではなく、実用的な設計上の決定です。そして、Foo Bar User がすでに言及しているように、allow_redirects引数を使用してこれを変更できます。
これは、POST ではなく、常にリダイレクトに対して GET を実行するブラウザの動作を模倣しています。
ウィキペディアには、この動作についての説明があります。元の標準では、ブラウザは POST でリダイレクトすることになっていましたが、すべて GET で実装していました。これを明確にするために、ステータス コード 303 と 307 が導入されました。303 は現在の (GET) 動作、307 は本来意図されていた動作 (POST) ですが、実際にはほとんど使用されません。
ウィキペディアによると、リクエストが行ったことは正しいです。Web サーバーがリダイレクトを必要とし、同じメソッドを使用する場合は、送信する必要があります307 Temporary Redirect (since HTTP/1.1)。
302件見つかりました
これは、標準に反する業界慣行の例です。HTTP/1.0 仕様 (RFC 1945) では、クライアントが一時的なリダイレクトを実行する必要がありました (元の記述フレーズは「Moved Temporarily」でした)[6]が、一般的なブラウザー は 303 See Other の機能を備えた 302 を実装しています。したがって、HTTP/1.1 は、2 つの動作を区別するためにステータス コード 303 と 307 を追加しました。ただし、一部の Web アプリケーションおよびフレームワークは、302 ステータス コードを 303 のように使用します。