ProfessionalCommunity Edition

HTTP settings

• Last updated: December 19, 2024

• Read time: 4 Minutes

The HTTP settings enable you to configure:

• Allowed redirect types.
• Streaming responses.
• Status 100 response handling.
• HTTP/1 settings.
• HTTP/2 settings.

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.

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.

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.

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.

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 tools in Burp:

• Use the Protocol toggle in the Inspector panel to override this setting. For example, use this in Burp Repeater requests or an intercepted request in Burp Proxy.
• Use the HTTP version Burp Intruder attack setting to override this setting for a specific Intruder attack. For more information, see Burp Intruder attack settings.

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

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