Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

Bodyless response delayed ~10sec before forwarding the header

dog | Last updated: Jul 12, 2018 10:36AM UTC

Whilst conducting some testing I noticed that for a bodyless response like a 302 (that as per spec does not have a content-length/chunked header) the proxy waits ~10sec before forwarding the header, and when it is forwarded Burp has also added a content-length header with a zero value.

PortSwigger Agent | Last updated: Jul 12, 2018 10:37AM UTC

Hi Martin, Thanks for getting in touch. Does the request have "Transfer-encoding: chunked" ? If not, I believe that's an invalid POST request and Burp is falling back to waiting 10s for a body. If it does have chunked encoding, would you be able to share the precise request? You can email support@portswigger.net to avoid posting it publicly.

Burp User | Last updated: Jul 12, 2018 12:31PM UTC

Actually I've had a good look at this and it's not the response but the request: a bodyless request (like a POST) that does not include a content-length header with a zero value is delayed for ~10sec ...

Burp User | Last updated: Jul 13, 2018 06:53AM UTC

No, the request doesn't have a chunked header either. After having a google, this looks like one of those RFC grey areas where the implementation seems to be vary and the forums are full of theological debate. A quick look through a few common web servers show that they happily accept a bodyless POST with neither a content-length or transfer-encoding header. Happy to close.

PortSwigger Agent | Last updated: Jul 13, 2018 09:14AM UTC

Hi Martin, Thanks for following up. I see, perhaps we could handle this invalid request a bit better. We're a bit adverse to change the network stack at the moment, it is mostly rock-solid, give to take a few corner-cases. I'll close this down for now; we may visit in the future when we look at networking in detail.

You must be an existing, logged-in customer to reply to a thread. Please email us for additional support.