Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

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

Here: https://i.ibb.co/c1xkfzn/burp-transfer-encoding.jpg (I only removed application-level company data and headers)

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