Skip to content

Fix all requests timeouting in Burp Suite's Repeater

Published on in Miscellaneous

Make sure you are not missing two empty lines after the request headers. There's a UX lesson here.

Table of contents

Skip table of contents

Problem

I was using Burp Suite (Community Edition, version 2023.12.1.5) for the first time.

Sending requests in the Repeater tab resulted only in timeouts:

HTTP/1.1 408 Request Time-out
Content-length: 110
Cache-Control: no-cache
Connection: close
Content-Type: text/html

<html><body><h1>408 Request Time-out</h1>
Your browser didn't send a complete request in time.
</body></html>

Solution

Adding two empty lines after the request headers fixed it for me.

Before:

GET /wiki/Main_Page HTTP/1.1
Host: en.wikipedia.org
Accept: */*

After:

GET /wiki/Main_Page HTTP/1.1
Host: en.wikipedia.org
Accept: */*

I found the solution and an explanation from a thread on Burp Suite User Forum:

Andre: I found a solution to this. I was removing the 2 extra lines from the request when adding the new header. If I keep them, the requests go through. [...]

Diego: I was having the same issue, but like Andre said above, one of the blank lines of the request had been removed. Adding it back made requests in Repeater work again.

Uthman, PortSwigger Agent: Thanks for your feedback. You can find more information on why this (\r\n\r\n) is required in the RFC 2616 documentation.

UX lesson

That's terrible UX:

  • The UI doesn't tell that the two empty lines are required.
  • The problem (all requests timeouting) is confusing.
    • I bet most users are not so intimately familiar with RFC 2616 that they can right off the bat deduct that "Oh, right, all requests seem to be timeouting, so I must have forgotten the two trailing newlines required in section 5 of RFC 2616!"

How I would fix this UX issue:

  • The UI should show a warning or an error if the empty lines are missing.
  • Or better yet, the app should add the missing empty lines automatically when the user sends a request.
    • To be fair, the app seems to add the empty trailing lines automatically, but inconsistently (maybe only when using HTTP/2).

I guess the "UX lesson" can be generalized like so: communicate obscure requirements to the user, and auto-fix issues where possible.