Get involved in the Burp challenge for opportunities to test your skills and win swag  –   Challenge me

PROFESSIONALCOMMUNITY

HTTP settings

  • Last updated: November 25, 2022

  • Read time: 4 Minutes

The HTTP settings enable you to configure:

Allowed redirect types

These settings control the redirect types that Burp can use. Select from the following redirect types:

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

Note

Burp's behavior in following redirects is determined by the configuration of the individual Burp tools (for instance, the Target scope).

The Allowed redirect types settings are project settings. They apply to the current project only.

Streaming responses

These settings enable you to identify URLs that return "streaming" responses - these are responses that do not terminate. Burp handles these responses differently to normal responses.

Streaming responses are often used for functions such as continuously-updating price data in trading applications. Typically, some client side script code makes a request and the server keeps a response stream open, pushing further data in real time as it becomes available.

However, intercepting proxies can break these applications because they use a store-and-forward model. In this case, the Proxy waits indefinitely for the streaming response to finish, and none of the response is ever forwarded to the client.

Burp's tools handle streaming responses in the following ways:

  • The Proxy passes these responses straight through to the client in real time.
  • Repeater updates the response panel in real time as data is received.
  • All other tools ignore streaming responses and close the connection.

To add a URL to the streaming responses list, click Add and enter the required details.

Note

Streaming response URLs use Burp's standard URL matching rules. For more information, see URL-matching rules.

You can also edit and reorder the rules in the list if required.

There are two other options available:

  • Store streaming responses - This setting causes Burp to store streaming responses in full. This option is necessary if you wish to view the contents of streaming responses within the Proxy history and Repeater response panel. Note that storing streaming responses may result in large temporary files.
  • Strip chunked encoding metadata in streaming responses - Streaming responses are generally chunked-encoded over HTTP. If you select this option, Burp removes the chunked encoding metadata which makes the responses more easily readable within Burp. Note that removing this metadata may break the client-side application.

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

Note

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

The Streaming responses settings are project settings. They apply to the current project only.

Status 100 response handling

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

The following settings are available:

  • Understand 100 Continue responses - Burp skips the interim response and parses the "real" response headers for information such as status code and content type.
  • Remove 100 Continue headers - Burp removes any interim headers from the server's response before it is passed to individual tools.

The Status 100 response handling settings are project settings. They apply to the current project only.

HTTP/1

By default, Burp Suite opens a new TCP connection for each HTTP/1.1 request / response pair. If you select Use keep-alive for HTTP/1 if the server supports it, the system keeps the same TCP connection open for 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.

Note

This setting affects all Burp Suite tools that send HTTP requests. However, you can override it for Repeater using the Enable HTTP/1 connection reuse menu option. For more information, see the Burp Repeater Options page.

The HTTP/1 settings are project settings. They apply to the current project only.

HTTP/2

By default, Burp uses HTTP/2 to communicate with all servers that advertise support for it during the TLS handshake. If you deselect Default to HTTP/2 if the server supports it then Burp uses HTTP/1 even if the server supports HTTP/2.

You can override this setting for individual requests using the Protocol toggle in the Inspector. You can only override editable contexts, such as Burp Repeater requests or an intercepted request in Burp Proxy.

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

Note

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

The HTTP/2 settings are project settings. They apply to the current project only.

Was this article helpful?