[BUG] Global HttpHandler modifies requests and breaks HTTP request smuggling

[pr0mers]

Prerequisites

• Thoroughly read the README file.
• Checked the project requirements and ensured they are met.
• Searched for existing issues that may address the problem.
• Performed basic troubleshooting steps.

Description

The extension registers a global HttpHandler that silently re-serializes in-scope requests, which breaks HTTP Request Smuggling testing in Repeater/Proxy. Because Repeater and Proxy are enabled by default, any request that contains parameters (including cookies) gets rebuilt via HttpRequest.withUpdatedParameters(...), causing Burp to re-parse and normalize the message and recalculate Content-Length — which destroys crafted CL.TE / TE.CL desync payloads.

The behavior is not obvious to the user, thus wasting lots of hours: there is no per-request indication that the extension mutated the outgoing request. It took a process of elimination (disabling extensions one by one) to trace a non-working smuggling lab back to OpenAPI Parser.

For deliberately malformed requests this is a problem. HTTP request smuggling (TE.CL / CL.TE)
relies on byte-exact requests with a manual Content-Length and/or duplicate headers. Once
The extension normalizes them, the desync never triggers — and there is no warning or log
line indicating the request was changed.

Steps to Reproduce

Honestly, this cost me about 4 hours on a TE.CL lab, convinced my payload or Burp
settings were wrong, before I finally isolated it , time I really shouldn't have had to
spend on an OpenAPI parser silently touching my traffic:

1. Install OpenAPI Parser (default settings — Proxy and Repeater in scope).
2. Open any HTTP Request Smuggling lab (e.g. a PortSwigger TE.CL lab).
3. Send a crafted smuggling request from Repeater (with a body/cookie, so hasParameters() is true).
4. Observe the desync does not work.
5. Disable OpenAPI Parser (or uncheck Repeater in its scope) → the exact same request now works.

Expected Behavior

Since this is an OpenAPI parser, it really shouldn't be touching requests with no OpenAPI. Could you either:

• The extension should not re-serialize / normalize a request when it has no actual parameter replacement to apply.

• It should not silently alter smuggling-style requests.

  At minimum, documenting this behavior and showing an indicator when a request is modified
  would save people from losing hours to it like I did.

Screenshots

No response

Environment

Extension: 2.3
Burp Suite: 2026.3.3
Java: OpenJDK 26.0.1
OS: Windows 10 Pro

Error Message

No response

Additional Context

No response