Options: HTTP

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

Redirections

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:

• 3xx status code with Location header
• Refresh header
• Meta refresh tag
• JavaScript-driven
• Any status code with Location header

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:

• The Proxy will pass these responses straight through to the client as data is received.
• Repeater will update the response panel in real time as data is received.
• Other tools will ignore streaming responses and will close the connection.

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:

• Store streaming responses - This causes Burp to store streaming responses in full. Using this option is necessary if you wish to view the contents of streaming responses within the Proxy history and Repeater response panel. Note that using this option may result in large temporary files.
• Strip chunked encoding metadata in streaming responses - Streaming responses are generally chunked-encoded over HTTP. If this option is selected, Burp will remove the chunked encoding metadata, making the responses more easily readable within Burp. Note that removing this metadata may break the client-side application, depending on how it is implemented.

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:

• Understand 100 Continue responses - If this option is checked, Burp will skip the interim response and parse the real response headers for response information like status code and content type.
• Remove 100 Continue headers - If this option is checked, Burp will remove any interim headers from the server's response before this is passed to individual tools.

HTTP/1

By default, Burp Suite opens a new TCP connection for each HTTP/1.1 request / response pair. If you select the Use keep-alive for HTTP/1 if the server supports it checkbox, then the system keeps the same TCP connection open so that it can be used by multiple request / response pairs. This brings significant benefits in speed and request timing.

Burp Suite closes any open TCP connections after five seconds of inactivity.

HTTP/2

By default, Burp speaks HTTP/2 to all servers that advertise support for it during the TLS handshake. If you deselect this option, Burp will use HTTP/1 even if the server supports HTTP/2.

Regardless of your settings here, you can override this default for an individual request using the Protocol toggle in the Inspector. Note that this only applies to editable contexts, such as in Burp Repeater or an intercepted request in Burp Proxy.

Burp provides two different options for working with HTTP/2 messages in a human-readable format. For more information, see the HTTP/2 documentation.