Closed AlecHaring closed 1 year ago
Header
stores the headers in a map
, which doesn't preserve order. So we can't trust the order of res.Header
, nor can we use the current method of transferring the response headers to the Burp response (Header().Add
).
Thank you for opening a issue. Initially, I only aimed for the request headers to have the correct order because those can be prone to fingerprinting/censorship whereas response headers are only relevant for the developer/security researcher using Burp.
To support response headers order, I think you need to dig deeper into the net/http
source code and find the code that writes the response header bytes into the header map. You can probably re-use the HeaderOrderKey to store the order.
I'd happily accept a PR for this.
Yeah, I suspected that was the case. Definitely not as important as the request header order, as you said. It was just something I noticed, and I thought I should report it.
I noticed you have a copy of net/http
in this repo with some patches. If needed, would you accept a PR that makes changes to that, or would you prefer a method that avoids changes to the net/http
source?
I noticed you have a copy of net/http in this repo with some patches. If needed, would you accept a PR that makes changes to that, or would you prefer a method that avoids changes to the net/http source?
If those changes are needed for a feature/fix you are adding then sure, go ahead.
Marked as wontfix
because I don't plan to work on this myself any time soon.
If you compare the response header order of a request with and without the extension enabled, you'll notice it's different.
GET http://httpbin.org/get
with extension:GET http://httpbin.org/get
without extension: