CODEWITHSUNDEEP
firefox-developer-tools
LSerni
LSerni

Reputation: 57398

Firefox Developer Tools NOT complaining about NOT valid JSON

I have an API endpoint whose response comes from a secondary server through a transparent proxy. Let us say that normally the answer is

{ "hello": "world" }

Due to the architecture (and yes, it is bad practice, but I haven't authority over this), the "transparent proxy" violates standards, injecting HTML messages in whatever passes through (PNG images included!). The headers are sent from the backend and are not touched by the proxy.

Occasionally, in the obvious scenario, the answer is, almost literally,

<div class="red">ERROR: session token not found</div>
{ "hello": "foobar" }

What is happening is that the backend answers with HTTP/200 and application/json, because it doesn't (and shouldn't) care about the HTTP token. It simply answers with something that's logically garbage (imagine an ATM that, if your PIN is correct, tells you your balance; but if it is incorrect, answers "Balance: 0", because the unauthenticated customer has a balance of 0).

On these occasions, as expected, the front end jQuery throws a fit since the answer is definitely not valid JSON, and I am informed through a .catch(xhr) fallback, and parsing its errorText I can recover the error text. So, I can tell the user that there was a problem, and what the problem was. From the front-end and application points of view, everybody lives happily ever after.

My small problem here is when debugging, because Firefox accepts the answer and displays it as if it was valid JSON, hiding the HTML as if it didn't exist:

{
    "hello": "foobar"
}

even if, toggling the [x] RAW switch in the same Firefox Developer Tools window, the non-JSON HTML preamble is displayed as expected, so I can see it's not JSON, albeit, jumbled as it is, I can't see much else:

<div class="red">ERROR: session token not found</div>
{"hello":"foob...

How can I ensure that Firefox Developer Tools will actually treat an invalid JSON as invalid, or show it visually (a flag, a red background...), without having to manually toggle the RAW switch off (to check for errors) and on (to inspect the contents) at each request? Which is unquestionably doable (indeed, it's what I'm doing now), but really irksome.

Example to reproduce

<!DOCTYPE html>
<html lang="en">
<head>
<title>JSONFail</title>
<meta charset="utf-8">
</head>
<body>
    <button onclick="json_test(0, '200 OK')">OK</button>
    <button onclick="json_test(1, '200 OK')">FAIL 200</button>
    <button onclick="json_test(2, '500 Some fail')">FAIL 500</button>
<script>
let XHR = (url) => {
    console.debug(';; XHR', url);
    return new Promise(function(resolve, reject) {
        const xhr = new XMLHttpRequest();
        xhr.open('GET', url, true);
        xhr.onload = function() {
            if (xhr.status == 200) {
                resolve(xhr);
            } else {
                reject(xhr);
            }
        };
        xhr.send(null);
    });
};
let json_test = (state, http_status) => {
    let xhr = XHR('json_serve.php?state=' + state
        + '&http_status=' + escape(http_status)
    );
    xhr.then(
        xhr => console.info(xhr)
    ).catch(
        xhr => console.error(xhr)
    );
};
</script>
</body>
</html>

<?php

header($_SERVER["SERVER_PROTOCOL"] . " " . $_GET['http_status']);
header('Content-Type: application/json;charset=utf-8');

if ($_GET['state'] == '0') {
    echo '{"hello": "world"}';
} else {
    echo '<div class="red">ERROR: session token not found</div>' . "\n";
    echo '{"hello": "foobar"}';
}

Upvotes: 1

Views: 285

Answers (1)

dumbass
dumbass

Reputation: 27202

This has been reported as bug 1708356. It is apparently an intentional (if overzealous) feature, meant to facilitate viewing JSON responses with XSSI mitigation sentinels. The discussion under the bug report does however suggest the feature is about to be limited.

Firefox ESR 78 is not affected, so until the ticket is resolved, you may consider downgrading; otherwise though, there is little you can do. Doing web development under the ESR version shouldn’t hurt either; since some users do prefer using the ESR version, it should pay off to keep compatibility with it.

Upvotes: 1

Related Questions