est31 Reporter
	Description • 7 years ago

If you apply curl -I to the URL [1] you are getting response headers like:

Content-Type: application/json
Content-Type: text/foo; charset=UTF-8

If you type that URL into a new tab, the Content-Type gets recognized as text/foo because it shows you a window "what to do with the file: download it, open it with program X". If it were recognized as json, you'd get the json view. However, if you then download and have the network console open, you see only one entry for the Content-Type, which is "Content-Type: application/json". This is also the same information exposed to web extensions via the webRequest API. If you have extension code like:

function headerRecv(responseDetails) {
	console.log("Headers received in response ", responseDetails);
}
browser.webRequest.onHeadersReceived.addListener(
	headerRecv,
	{
		urls: ["<all_urls>"],
		types: ["main_frame"]
	},
	["blocking", "responseHeaders"]
);

You get a message that contains only the "Content-Type: application/json" header as well.

Now per RFC 7230 [2] those double response headers are invalid (Content-Type allows no comma separated lists). But that doesn't mean that Firefox should exhibit inconsistent behaviour. I guess the best thing here would be to deduplicate the header consistent with the MIME type recognition logic.

[1]: https://httpbin.org/response-headers?Server=httpbin&Content-Type=text%2Ffoo%3B+charset%3DUTF-8
[2]: https://tools.ietf.org/html/rfc7230#section-3.2.2

	Andy McKay
	Comment 1 • 7 years ago

I thought I could find a duplicate, but I can't.

	psnyde2
	Comment 2 • 7 years ago

This may be the same issue as Bug 1377689

	Rob Wu [:robwu]
	Comment 3 • 6 years ago

Confirmed that bug exists in 58, but not in the current stable (60). So I assume that this has been fixed by bug 1377689.