デバッグプロキシで障害ケースを設計する

デバッグプロキシは、通常のサーバーがほとんど返さない応答にクライアントを出会わせたいときに役立ちます。まずクライアントの挙動を定義し、次にその状態を生み出す介入を選びます。

「リクエストが失敗した」は広すぎるテストケースです。正しい HTTP エラー応答、決して届かない応答、ダウンロードの途中で切断される接続は、アプリケーションにそれぞれ別のことを要求します。

正しい層で介入する

Charles はリクエストや応答を転送前に停止するブレークポイントを提供します。傍受したメッセージは検査・編集でき、通過させることも中止することもできます。Rewrite ツールは一致するヘッダー、URL、本文に繰り返し可能な変更を適用します。帯域制限は帯域幅と追加の遅延を制御します。

これらの制御は HTTP クライアントの挙動を試せますが、帯域制限はランダムな IP パケット損失の正確なモデルではありません。プロキシはデータをバッファリングし、接続を再利用し、別個の上流接続を開くことがあります。必要な条件が明確に HTTP より下の層にある場合は、ネットワーク劣化ツールを選んでください。

各ケースを解釈可能に保つ

対象のホストとパスを狭く一致させます。通常の通信から始め、変更を一つだけ有効にし、何を変えたかを記録します。再試行が別のエンドポイントに達する場合は、同じ規則をその試行にも適用すべきか決めます。そうしないと、無条件の書き換えがすべての復旧経路を元の失敗に変えてしまいます。

アップロードや支払いに似た操作では、応答が失われてもサーバーが要求を拒否したことにはなりません。すべての転送障害が安全に再試行できると主張するのではなく、その曖昧さを再試行のケースに含めてください。

HTTPS の内容を検査・編集するには、クライアントがデバッグプロキシの TLS 検査設定に参加する必要があります。CONNECT だけを運ぶプロキシは暗号化されたアプリケーションのバイト列を見ます。分離されたテスト設定を使い、その後に経路と信頼の設定を元に戻して、以降の観察が通常のクライアントを表すようにしてください。