HTTP設定では次の設定ができます:
Burpが使用できるリダイレクトタイプを制御します。次のリダイレクトタイプから選択します:
Burpがリダイレクトをたどる動作は、個々のBurpツールの設定(たとえばターゲットスコープに基づくなど)によって決まります。
リダイレクトさせるタイプ設定は、プロジェクト設定です。現在のプロジェクトにのみ適用されます。
レスポンスが終了しない"ストリーミング"レスポンスを返すURLを指定できます。Burpはこれらのレスポンスを、通常のレスポンスとは異なる方法で処理します。
ストリーミングレスポンスは、トレーディングアプリケーションで価格データを継続的に更新するような機能でよく使われます。通常、クライアント側のスクリプトコードがリクエストを生成し、サーバはレスポンスストリームを開いたままにし、利用可能になった継続データをリアルタイムにプッシュします。
インターセプトプロキシはストアアンドフォワードモデルを使用しているため、これらのアプリケーションを壊す可能性があります。このケースでは、Proxyはストリーミングレスポンスが終了するのを無限に待機し、クライアントには何も転送されないでしょう。
Burpのツールは、次の方法でストリーミングレスポンスを処理します:
ストリーミングレスポンスのリストにURLを追加するには、追加をクリックし、必要な情報を入力します。
ストリーミングレスポンスのURLは、Burpの標準的なURLマッチングルールを使用します。詳細は、URLマッチングルールを参照してください。
また必要に応じて、リスト内のルールの編集や並べ替えもできます。
その他に2つのオプションがあります:
ストリーミングレスポンスは多くの場合GZIPエンコーディングを使用して圧縮されています。ProxyとRepeaterの設定で、BurpがGZIPコンテンツを展開するよう設定できます。
(バイナリファイルのダウンロードのような)とても大きなレスポンスを処理する際にストリーミングレスポンスを使用すると、ストアアンドフォワードプロキシモデルをバイパスし、Burpのパフォーマンスを向上させられます。
ストリーミングレスポンス設定は、プロジェクト設定です。現在のプロジェクトにのみ適用されます。
ステータス100のHTTPレスポンスの処理方法を制御します。これらのレスポンスは、サーバにPOSTリクエストが送信された後、リクエストボディが転送される前に暫定的なレスポンスを返す場合によく発生します。
次の設定があります:
ステータス100レスポンスの処理設定は、プロジェクト設定です。現在のプロジェクトにのみ適用されます。
Burp Suiteはデフォルトで、1対のHTTP/1.1リクエスト/レスポンスごとに新しいTCP接続を開きます。サーバがサポートしている場合、HTTP/1でキープアライブを使用するを選択すると、システムは同じTCP接続を開いたままにして、複数のリクエスト/レスポンスで使用できるようにします。これにより、スピードとリクエストのタイミングに大きなメリットが生まれます。
Burp Suiteは、開いているTCP接続が5秒間非アクティブの場合、接続を閉じます。
この設定は、HTTPリクエストを送信するすべてのBurp Suiteツールに影響します。ただしRepeaterでは、メニューにあるHTTP/1接続を再利用するで上書きできます。詳細は、Burp Repeaterオプションページを参照してください。
HTTP/1設定は、プロジェクト設定です。現在のプロジェクトにのみ適用されます。
Burpはデフォルトで、TLSハンドシェイク時にHTTP/2のサポートを表明するサーバとの通信に、HTTP/2を使用します。サーバがサポートしている場合、デフォルトでHTTP/2にするの選択を解除すると、サーバがHTTP/2をサポートしていてもHTTP/1を使用します。
個々のリクエストに対して、Inspectorのプロトコルトグルでこの設定を上書きできます。Burp RepeaterのリクエストやBurp Proxyでインターセプトされたリクエストなど、編集可能なコンテキストでのみ上書きできます。
人間が読める形式でHTTP/2メッセージを操作するには、Burpには2つ方法があります。詳細は、HTTP/2ドキュメントを参照してください。
私たちはHTTP/2の機能のうち、Burp Suiteでの使用に関連する機能のみを実装しています。サーバプッシュなどの追加機能はサポートしていません。
HTTP/2設定は、プロジェクト設定です。現在のプロジェクトにのみ適用されます。