User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0 SeaMonkey/2.53.8.1

Steps to reproduce:

Create an XHR to a file, like:
const check = new XMLHttpRequest();
function checkStatus() {
check.onload = () => {
if (check.status === 200) { console.log('file is found!'); }
else { console.log('file not found!'); }
}
check.open("HEAD", "/check/myfile.txt", true);
check.send();
}

Put the function in a timed loop or setInterval, then repeatedly change the target resource filename to match then not match.

Actual results:

Once the XHR.status == 200 (resource found), it will continue to be 200, even if the resource no longer exists at the next XHR.send().

Expected results:

The XHR.status should not be cached. For reference, Chrome does not have this issue.

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Networking' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Presumably we shouldn't be caching HEAD requests at all.

https://datatracker.ietf.org/doc/html/rfc2616#section-9.4

The response to a HEAD request MAY be cacheable in the sense that the
information contained in the response MAY be used to update a
previously cached entity from that resource.

Not working on this right now.