The Burp Suite User Forum was discontinued on the 1st November 2024.

Burp Suite User Forum

For support requests, go to the Support Center. To discuss with other Burp users, head to our Discord page.

SUPPORT CENTER DISCORD

Burp returning Transfer-Encoding: chunked

Gregory | Last updated: Mar 26, 2019 08:47PM UTC

Hello, Based on what I saw here: https://support.portswigger.net/customer/portal/questions/9700504-apache-tomcat-transfer-encoding-bug If I undestand correctyl: Burp is dealing with the chunked reconstruction and then provides the user with a corresponding Content-Length (making it look like a seemlessly standard not chunked response). On the 2 versions I am currently using: * community edition 1.7.36 * pro 2.0.18beta After dealing with a chunked exchange, Burp returns a response with Transfer-Encoding: chunked header. This makes my application making that request fail since it has an invalid HTTP response(Transfer-Encoding header but no chunked meta-data): ********************** stacktrace ******************************************** File "C:\Python37\lib\site-packages\requests\models.py", line 753, in generate raise ChunkedEncodingError(e) requests.exceptions.ChunkedEncodingError: ('Connection broken: IncompleteRead(226 bytes read)', IncompleteRead(226 bytes read)) ******************************************************************************** Basically what I read in the other thread would indeed be the correct behaviour: striping metadata AND transfer-encoding header. When I run the identical HTTP requests without going through burp its all fine. Note: This is all happening over HTTPS. Workaround: I am auto-removing this using auto-replace in response functionality.

PortSwigger Agent | Last updated: Mar 27, 2019 10:02AM UTC

Thanks for letting us know about this. I just tried a similar scenario using Burp 2.0.18 and Burp correctly translated the chunk response, including removing the Transfer-Encoding header. Could you send a screenshot of the issue occurring?

PortSwigger Agent | Last updated: Mar 27, 2019 10:54AM UTC

Thanks for following up. I've investigated the relevant code and can't see a likely cause. To investigate this further, could you let us know the server details? You can send them to support@portswigger.net so they're not visible on this public board. Alternatively, if you could capture the raw response - not through Burp but using openssl s_client or similar - and send to us as an unredacted text file, we can use that as well.

Burp User | Last updated: Mar 27, 2019 01:36PM UTC