Research Academy
My account Customers About Blog Careers Legal Contact Resellers
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 changes response headers case

rafael | Last updated: May 08, 2021 03:40PM UTC

I noticed that during http2 requests BURP changes the response headers to "First Capital" so any reponse header like some-somethingelse-anything : any value will be replaced as Some-Somethingelse-Anything : any value I know http2 headers are case insensitive and it should't be a problem but it isnt up to burp decide or not to change the casing of headers... and if so it should allow me to stop it from doing according to http2 rcf ALL HEADERS SHOULD BE LOWERCASE https://tools.ietf.org/html/rfc7540#section-8.1.2 Is there any way to stop burp from having this bad behavior? if not how can report a bug?

Uthman, PortSwigger Agent | Last updated: May 10, 2021 10:59AM UTC

Thanks for reporting this. Our development team is looking at improving this behavior in the future.

Uthman, PortSwigger Agent | Last updated: May 10, 2021 11:07AM UTC

I have some further feedback: The headers are sent over the wire in lowercase but they are capitalized in Burp.

Adam | Last updated: Oct 24, 2021 08:38AM UTC

I have the same issue but with request headers. It affects my testing as app expects lowercase headers so when I proxy the app experience issues.

Hannah, PortSwigger Agent | Last updated: Oct 25, 2021 08:54AM UTC

Hi Is your app using HTTP/2? When you look at your request headers, are you looking at them in the message editor, or in the Inspector panel?

Adam | Last updated: Oct 27, 2021 10:01AM UTC

here is the request line: GET /path/to/api/endpoint HTTP/1.1 So I guess it is not using HTTP/2 Do we have to use HTTP/2 for headers to be in lower case?

Adam | Last updated: Oct 27, 2021 10:02AM UTC

I look at requests in http proxy "HTTP History"

Hannah, PortSwigger Agent | Last updated: Oct 27, 2021 02:11PM UTC

Hi Burp should not be modifying the contents of an HTTP/1.1 request. Have you set up an external browser to use with Burp (https://portswigger.net/burp/documentation/desktop/external-browser-config), or are you using the embedded Chromium browser? Have you tried sending your original request through Repeater, then changing the header capitalization to lower-case, and sending the request? If so, is there a difference between the two responses?

Adam | Last updated: Oct 28, 2021 12:21AM UTC

Yes, I have setup browser but the requests modified are from mobile app not browser. yes I think if the headers are lower case when it gets send the receiving party is not changing it's state. what I tried is not to use burp in-between and the response was as expected as headers were received lower case.

Craig | Last updated: Dec 14, 2021 11:38AM UTC

Burp v2021.10.3 proxying non-embedded Chromium is indeed modifying the HTTP headers for 1.1 requests. DevTools in the non-embedded browser shows client sending HTTP header: x-client: BLAH Burp shows this within logger as: X-Client: BLAH ....and sends it on the wire this way too, as per request log (Project Options->Misc->Logging request log). I noticed this as the target app expected this http header name to be lowercase and consequently it was generating errors. To workaround this I've added proxy match and replace rules to replace relevant HTTP headers in requests to be lowercase, but this is not ideal.

Hannah, PortSwigger Agent | Last updated: Dec 14, 2021 11:49AM UTC

Hi Is it possible for you to share the application that you are seeing this behavior with so that we can try to replicate this? You can drop us an email at support@portswigger.net

a | Last updated: Jun 04, 2024 02:02PM UTC

Hi I want to notify that the issue still persists. I'm currently testing a mobile app where the backend expects an uppercase header ("REG-TOKEN"), but Burp is changing the casing ("Reg-Token"), so the server rejects the requests made when I'm intercepting the traffic generated by the mobile app. The app is using HTTP/1.1 I've been testing this app a couple of years in a row, and I always have the same problem. It would be nice if Burp sends the request exactly how the client sends it, to avoid problems like this.

Hannah, PortSwigger Agent | Last updated: Jun 05, 2024 09:15AM UTC