プロキシ認証の再試行と再送できないアップロードボディ
認証の再試行がワンショットのアップロードストリームを露呈しうる理由を理解し、境界付きバッファリングか再送可能なコンテンツを意図的に選びましょう。
GET はプロキシ経由で認証できても、POST や PUT は再送できないボディや巻き戻しエラーで失敗することがあります。アカウントは正しい可能性があります。認証のやり取りが、クライアントがすでにアップロードを消費した後に別のリクエストを要求することがあるからです。
| ボディのソース | 再送の選択 |
|---|---|
| 小さく有限なボディ | 境界付きバッファはそのバイトを保持できます。 |
| シーク可能なファイル | クライアントが対応する巻き戻しインターフェースにより再送可能にできます。 |
| ジェネレータ、パイプ、ライブプロデューサ | ワンショットのソースには別の設計が必要かもしれません。 |
libcurl は多段階認証を含む用途向けにシークコールバックを文書化しています。Jersey はコネクタの挙動に応じてバッファ付きおよび分割されたエンティティ処理モードを提供します。 Jersey 2 Apache コネクタの例 はバッファ付き設定を示しています。どちらも無制限のインメモリアップロードを適切にはしません。
失敗するメソッドとボディのソースを再現してください。準備用の GET には再送するアップロードがなく、後続のアップロードがそれと同じ接続や認証状態を共有することも証明しません。新しい宛先、クライアントオブジェクト、接続ポリシーで変わりえます。ファイルベースのボディとライブストリームも、サンプルテキストが同じでも異なります。
バッファする場合は、サイズ上限、保存場所、寿命を定義してください。同時アップロードはコストを倍加させ、機密データはバッファが置かれる場所に残ります。
既知の互換プロキシへの事前認証 は最初のチャレンジを 1 回回避できます。しかし、別の試行を要求しうる以降の認証ラウンド、リダイレクト、切断された接続をすべて排除することはできません。
プロキシの応答、ボディの消費点、再送エラーを一緒に保ってください。次に、プロトコルの再送と不確実なアプリケーション結果を区別します。応答が失われる前に送信が処理されていた可能性があります。再送する前に宛先の冪等性ルールに従ってください。