For a HEAD request, a web server is returning a Content-Type header with a single media type, but Response.headers.get('content-type') in Firefox returns a comma-separated list, including a value not in the actual header.
Categories
(DevTools :: Netmonitor, defect)
Tracking
(Not tracked)
People
(Reporter: reeder_29, Unassigned)
Details
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:151.0) Gecko/20100101 Firefox/151.0
Steps to reproduce:
Using Firefox 151.0.4 (64-bit) running on a Mac with 3.8 GHz 8-Core Intel Core i7 running MacOS Tahoe 26.5.1, a webapp (https://group-viewer.surge.sh/node-graph-presenter/) made a a HEAD request to a server using fetch (line 312 at the moment, of selectable-node-graph.js):
const headResponse = await fetch(graphUrl, {method: 'HEAD'});
where graphUrl is https://rs.hominidsoftware.com/storage/doug/public/shares/260528-1604-Sample3.csv
Curl shows the headers as:
$ curl -I https://rs.hominidsoftware.com/storage/doug/public/shares/260528-1604-Sample3.csv
HTTP/1.1 200 OK
Server: nginx
Date: Sun, 14 Jun 2026 01:10:04 GMT
Content-Type: text/csv; charset=binary
Content-Length: 17427
Connection: keep-alive
Vary: Accept-Encoding
Content-Security-Policy: sandbox allow-orientation-lock;default-src 'none';script-src 'none';script-src-attr 'none';style-src 'self';img-src 'self';font-src 'self';object-src 'none';child-src 'none';connect-src 'none';base-uri 'self';frame-ancestors 'none';form-action 'none';upgrade-insecure-requests
Cross-Origin-Opener-Policy: same-origin
Origin-Agent-Cluster: ?1
Referrer-Policy: no-referrer
Strict-Transport-Security: max-age=15552000; includeSubDomains
X-Content-Type-Options: nosniff
X-DNS-Prefetch-Control: off
X-Download-Options: noopen
X-Frame-Options: SAMEORIGIN
X-Permitted-Cross-Domain-Policies: none
X-XSS-Protection: 0
Access-Control-Allow-Private-Network: true
Vary: Origin
Access-Control-Allow-Credentials: true
Access-Control-Expose-Headers: ETag
Cache-Control: public, no-cache
ETag: "89db68fb0f60149d22ed51fa81d3d268"
Actual results:
The server returned the following raw headers:
HTTP/1.1 200 OK
Server: nginx
Date: Sun, 14 Jun 2026 00:59:28 GMT
Content-Type: text/csv; charset=binary
Connection: keep-alive
Vary: Accept-Encoding
Content-Security-Policy: sandbox allow-orientation-lock;default-src 'none';script-src 'none';script-src-attr 'none';style-src 'self';img-src 'self';font-src 'self';object-src 'none';child-src 'none';connect-src 'none';base-uri 'self';frame-ancestors 'none';form-action 'none';upgrade-insecure-requests
Cross-Origin-Opener-Policy: same-origin
Origin-Agent-Cluster: ?1
Referrer-Policy: no-referrer
Strict-Transport-Security: max-age=15552000; includeSubDomains
X-Content-Type-Options: nosniff
X-DNS-Prefetch-Control: off
X-Download-Options: noopen
X-Frame-Options: SAMEORIGIN
X-Permitted-Cross-Domain-Policies: none
X-XSS-Protection: 0
Access-Control-Allow-Private-Network: true
Access-Control-Allow-Origin: https://group-viewer.surge.sh
Vary: Origin
Access-Control-Allow-Credentials: true
Access-Control-Expose-Headers: ETag
Cache-Control: public, no-cache
ETag: W/"89db68fb0f60149d22ed51fa81d3d268"
Content-Encoding: gzip
However, right-clicking on the response in the Network tab of the Web Developer Tools and selecting Copy Response Headers get this:
HTTP/2 421
server: nginx
date: Sun, 14 Jun 2026 00:59:28 GMT
content-type: text/html
content-length: 166
X-Firefox-Spdy: h2
Note that the content-type is entirely different.
The next line of JavaScript extracts the content-type:
contentType = headResponse.headers.get('content-type')
The value saved to contentType is text/html,text/csv; charset=binary, a comma-separated list of the hallucinated and actual headers.
Expected results:
headResponse.headers.get('content-type') should have returned the value actually sent.
The same error happens when the returned content-type is application/json; charset=binary
Comment 1•2 months ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Security: Process Sandboxing' component, but is not confident enough to move the bug to that component.
Comment 2•2 months ago
|
||
The severity field is not set for this bug.
:Mardak, could you have a look please?
For more information, please visit BugBot documentation.
The trigger may be that the Content-Type has a parameter charset=binary, where binary is not a legal value
Comment 4•1 month ago
|
||
Moving to DevTools, could potentially also be Core :: Networking component, but looks more like devtools data types to me right now.
Comment 5•1 month ago
|
||
The issue seems to be about the discrepancy between what the JS API returns and what the server returned.
reeder_29: we cannot reproduce the issue at the moment, can you share exact steps to reproduce? When running
res = await fetch("https://rs.hominidsoftware.com/storage/doug/public/shares/260528-1604-Sample3.csv", {method: 'HEAD'});
res.headers.get('content-type')
in the console, we always get "text/csv; charset=binary" and we don't see a 421 response status either. Thanks
My Firefox has updated itself to v152.0.6 (64-bit), and I'm not observing the problem now. :-S
Comment 7•1 month ago
|
||
Thanks for checking. I will close as invalid for now, assuming that this is solved.
Given the symptoms it's a bit hard to know in which area the bug might have been fixed.
Please re-open if this happens again!
Updated•1 month ago
|
Description
•