Options: HTTP

This tab contains settings to control how Burp handles HTTP redirections, streaming responses and status 100 responses.


These settings control the types of redirections that Burp will understand in situations where it is configured to follow redirections.

The following types of redirection can be selected:

Note that Burp's behavior in following redirections to particular targets is determined by settings within each individual Burp tool (for instance, based on Target scope).

Streaming responses

These settings let you inform Burp which URLs return "streaming" responses, which do not terminate. Burp will then handle these responses differently than normal responses.

Streaming responses are often used for functions like continuously updating price data in trading applications. Typically, some client side script code makes a request, and the server keeps the response stream open, pushing further data in real time as this becomes available. Because intercepting proxies use a store-and-forward model, they can break these applications: the Proxy waits indefinitely for the streaming response to finish, and none of it is ever forwarded to the client.

Streaming responses are handled in the following way by individual Burp tools:

For help configuring the list of streaming URLs, refer to the help on URL matching rules.

Two further options are available relating to streaming responses:

Streaming responses are often compressed using GZIP encoding - you can configure Burp to decompress this content via the normal options in the Proxy and Repeater configurations.

Note that you can also use the streaming responses support for handling very large responses that are not strictly streaming (such as binary file downloads), in order to bypass the store-and-forward proxy model and improve Burp's performance.

Status 100 responses

These settings control the way Burp handles HTTP responses with status 100. These responses often occur when a POST request is sent to the server, and it makes an interim response before the request body has been transmitted.

The following settings are available:


This setting controls whether Burp attempts to use HTTP/2 for inbound and outbound communication over TLS. It is enabled by default.

As long as this control is enabled, you continue to work with HTTP/1 messages within Burp's tools. However, Burp will convert all outgoing messages from this text-based format to their binary HTTP/2 equivalents, and reverse this process for incoming messages. This allows you to read and edit HTTP/2 messages within Burp in exactly the same way as HTTP/1 messages.

The first request you send will always indicate HTTP/1 in the request line. If Burp successfully establishes HTTP/2 communication with the server, all subsequent messages will indicate this in the request line and status line respectively. For example:

  1. GET / HTTP/1.1
    HTTP/2 200 OK
  2. GET /example HTTP/2
    HTTP/2 200 OK

Note: We have only implemented the core features of HTTP/2 that are relevant for use with Burp Suite. Additional features, such as server push, are not supported.