gin の Context.Redirect の単体テストは GET 応答コードでは機能しますが、POST 応答コードでは機能しません (golang)

Go 言語で Web アプリケーションを作成する場合、HTTP リクエストとレスポンスを処理するために gin フレームワークを使用することがよくあります。単体テストを実行するときは、コードの品質と安定性を確保するためにコードのカバレッジ テストを実行する必要があります。ただし、gin の Context.Redirect メソッドの単体テストは、GET リクエストを処理する場合にはうまく機能しますが、POST リクエストを処理する場合にはうまく機能しません。この記事では、PHP エディターの Apple が、この問題が発生する理由を詳しく説明し、単体テストの POST リクエストに対するいくつかの解決策を提供します。

質問内容

サーバーで特定のエンドポイントを別のサーバーにリダイレクトしたいと考えています。エンドポイントは getted または posted できます。どちらの場合も、http 応答コードは 302 である必要があります。このコードで curl を使用すると、どちらの場合も応答コード 302 が表示され、curl -l はリダイレクトに正しく続きます。おお。

＃＃＃＃＃＃しかし＃＃＃＃＃＃

私の単体テストでは httptest.newrecorder() を使用して情報を取得しますが、これは

get

でのみ機能し、post では機能しません。したがって、実際のリダイレクトが機能していることがわかっているときに単体テストを機能させる方法を理解する必要があります。失敗したテストでは、http 応答コードが 302 ではなく 200 (http.statusfound) であることが示されています。 リーリー これは独立したテストです。 リーリー 実際のアプリケーション (図示せず) でcurl postを実行すると、動作していることがわかります:

$ go run foo.go
post code 200
get code 302

解決策

tl;dr

解決策は、

context.redirect

の後に

context.writer.writeheadernow

を明示的に呼び出すことです。 イラスト これは、

gin.createtestcontext

から返された gin コンテキストを使用するエッジ ケースです。

get リクエストの場合、gin は最終的に http.redirect を呼び出し、応答に短い HTML 本文を書き込みます (

found

)、応答のステータス コードが書き込まれます。 投稿リクエストの場合、http.redirect 短い HTML 本文は書き込まれず、ステータス コードが応答に書き込まれる可能性はありません。

「http 実装」を参照してください。リダイレクト 。ソース コードによると、

content-type

ヘッダーが以前に設定されていた場合、get リクエストでも同じ問題が発生します。 リーリー 解決策は、context.writer.writeheadernow: を明示的に呼び出すことです。 リーリー

gin 自体も同じ回避策を使用します。

testcontextrenderredirectwithrelativepathを参照してください。

(*engine).handlehttprequest が writeheadernow

を呼び出すため、実際のサーバー アプリケーションは同じ問題に悩まされることはありません (

ソース コードを参照 ）。だからこそ、私はこれを「バグ」ではなく「エッジケース」と呼んでいます。

以上がgin の Context.Redirect の単体テストは GET 応答コードでは機能しますが、POST 応答コードでは機能しません (golang)の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。