Dev Tools override on a domain caused response 'true' to be parsed incorrectly

[bjorn-einar-bjartnes-4ss]

When I have an active rule on an override on a domain, even if it did not match the HTTP request other than being on the same domain, the response application/json with value true, which is valid json text,
is parsed as

When disabling overrides, it is back to

I checked, the response is pure ASCII, seems to be nothing fuzzy about it, but it gets wrongly presented in the tools and parsing in the application fails, so somehow the response has been tampered with.

* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
< HTTP/2 200
< date: Wed, 19 Jun 2024 09:22:59 GMT
< content-type: application/json; charset=utf-8
< access-control-allow-credentials: true
< access-control-allow-origin: https://xxxxxxxxxxx
< vary: Origin
< strict-transport-security: max-age=2592000
< request-context: appId=cid-v1:xxxxxxxxxxxxxxxxx
< api-supported-versions: 1.0-internal, 1.0
< x-powered-by: ASP.NET
< x-azure-ref: xxxxxxxxxxxxxxxxxxxxxxxxxxx
< x-cache: CONFIG_NOCACHE
<
* Connection #0 to host xxxxx  left intact
true⏎

[captainbrosset]

Thanks for reaching out and reporting this. Can you please help me investigate this a bit by providing more details on the override that you've used?
I've set up a local test to try and reproduce the problem, but no luck so far.

My test is:

• An index.html document with a single button.
• A script tag in the HTML that contains an event listener for button click events, which fetches the data.json file
• A data.json file that contains true as its only content.

Then, in DevTools, I right click on the index.html request in the Network tool, and click Override Content. I then override the HTML content to add something unrelated.

I then reload the page, click the button, and inspect the response from the fetch request, and I see true, as expected.

So, obviously, I'm missing something from your setup.

[jpambrun]

I have the same issue. Adding a header override for a path that wont match anything, for a header that no one looks for

somehow breaks all files from that domain. In my case the files are binary in binary format. They look fine in the network tab, but are broken when parsed in the app.

[jpambrun]

I could reproduce in Chrome 138.