Closed Bug 2047399 Opened 2 months ago Closed 1 month ago

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)

Firefox 151
defect

Tracking

(Not tracked)

RESOLVED WORKSFORME

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

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.

Component: Untriaged → General

The severity field is not set for this bug.
:Mardak, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(edilee)

The trigger may be that the Content-Type has a parameter charset=binary, where binary is not a legal value

Moving to DevTools, could potentially also be Core :: Networking component, but looks more like devtools data types to me right now.

Component: General → Netmonitor
Flags: needinfo?(edilee)
Product: Firefox → DevTools

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

Flags: needinfo?(reeder_29)

My Firefox has updated itself to v152.0.6 (64-bit), and I'm not observing the problem now. :-S

Flags: needinfo?(reeder_29)

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!

Status: UNCONFIRMED → RESOLVED
Closed: 1 month ago
Resolution: --- → INVALID
Resolution: INVALID → WORKSFORME
You need to log in before you can comment on or make changes to this bug.