Netmonitor should explain why JS request blocked due to mimetype mismatch has no response
Categories
(DevTools :: Netmonitor, enhancement, P3)
Tracking
(Not tracked)
People
(Reporter: pomax, Unassigned)
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:120.0) Gecko/20100101 Firefox/120.0
Steps to reproduce:
When loading a JS module, loading a non-existant URL and getting a 404 HTML page back causes Firefox to not even bother loading the actual response in the dev tools network tab.
I ran a localhost server with a trivial index.html that tries to load a module script:
<!doctype html>
<html>
<head>
<meta charset="utf-8">
<title>demo</title>
<script src="test.js" type="module" defer></script>
</head>
<body></body>
</html>
Since test.js does not exist, that request will be sent a 404 HTML page instead.
Actual results:
console error:
Loading module from “http://localhost/test.js” was blocked because of a disallowed MIME type (“text/html”).
network tab:
a network entry with status "(x)" instead of "404", an "NS_ERROR_CORRUPT_CONTENT" in the "transferred" column, and an empty response, despite the header clearing showing a 404 status and text/html content-type for the response.
Expected results:
The dev tools' network tab's "response" tab for the request should show a 404 as status code, a normal bytesize in the "transferred" column, and show the actual html code as response, so that people can see what they got instead of what they thought they were going to get.
It seems like Firefox is hardcoded to only view the network request through the lens of "this can only ever be JS", which for URLs is very much not the case. Instead, it should be looking at the response content-type and only apply JS logic (like flagging the content as corrupt) if the content-type is "application/javascript".
|
||
Comment 1•2 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'DevTools::Netmonitor' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Comment 2•2 years ago
|
||
Valentin, do you know if we try to get the full response content when we fetch a script and see that the mime type is wrong? We see the following error: NS_ERROR_CORRUPTED_CONTENT. I'm not sure we are actually reading the response after getting the response headers.
|
||
Comment 3•2 years ago
|
||
If the mime type doesn't match, we end up cancelling the channel with that status code here
I think we might still be able to check the responseStatus of the channel, but I don't think we'll be getting the full body of the request.
|
|
||
Comment 4•2 years ago
|
||
Note that Chrome doesn't show the full response either, just the status code.
|
|
||
Comment 5•2 years ago
|
||
Thanks a lot, that makes sense. I guess DevTools could show a more meaningful message, but otherwise it sounds like what we have here is correct.
I will reclassify as enhancement.
Description
•