1483680 - image/apng in content-type response header causes HTML content to be incorrectly displayed as APNG Image

Status: RESOLVED WORKSFORME

(Core :: DOM: Navigation, defect, P2)

Description

[13hu]

To reproduce:
 - Visit https://example.com/index.htm in Firefox
This URL is a 404 with HTML content.

Expected: Page content is displayed as HTML

Actual: Firefox tries to render page as APNG image, shows cannot be displayed error because the content is HTML, not image.

Request headers:

Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
DNT: 1
Connection: keep-alive
Upgrade-Insecure-Requests: 1


Response headers:

HTTP/2.0 404 Not Found
content-encoding: gzip
accept-ranges: bytes
cache-control: max-age=604800
content-type: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
date: Wed, 15 Aug 2018 20:38:59 GMT
expires: Wed, 22 Aug 2018 20:38:59 GMT
last-modified: Sat, 11 Aug 2018 21:34:41 GMT
server: ECS (dca/24D2)
vary: Accept-Encoding
x-cache: 404-HIT
content-length: 606
X-Firefox-Spdy: h2


FF seems to interpret the content-type response "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8" as apng

Chrome renders the page correctly as HTML.

Comment 1

[Edgar Chen [:edgar]]

I could reproduce on 57, but not 51. Looks like a regression.

Comment 2

[Edgar Chen [:edgar]]

Regression window from my side,

 6:35.53 INFO: Narrowed nightly regression window from [2016-08-08, 2016-08-11] (3 days) to [2016-08-10, 2016-08-11] (1 days) (~0 steps left)
 6:35.53 INFO: Got as far as we can go bisecting nightlies...
 6:35.53 INFO: Last good revision: 6cf0089510fad8deb866136f5b92bbced9498447 (2016-08-10)
 6:35.53 INFO: First bad revision: 0502bd9e025edde29777ba1de4280f9b52af4663 (2016-08-11)
 6:35.53 INFO: Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6cf0089510fad8deb866136f5b92bbced9498447&tochange=0502bd9e025edde29777ba1de4280f9b52af4663

Comment 3

[Honza Bambas (:mayhemer)]

(In reply to Edgar Chen [:edgar] from comment #2)
> pushloghtml?fromchange=6cf0089510fad8deb866136f5b92bbced9498447&tochange=0502
> bd9e025edde29777ba1de4280f9b52af4663

I can see bug 1160200 in this range, but it may only uncover a different, more general bug.

Comment 4

[Daniel Veditz [:dveditz]]

Seems to be working fine now. Must've gotten fixed in a duplicate somewhere along the way.

Comment 5

[Daniel Veditz [:dveditz]]

Or maybe not "fixed" in Firefox: example.com now sends a sensible header rather than (apparently?) echoing back the Accept: values:

content-type: text/html; charset=UTF-8

Since Content-Type is defined as having only one value, browsers interpret the commas as indicating coalesced multiple headers and split them there. Then maybe we chose the last header ("/" is invalid and ignored). Chrome may have chosen the first occurrence rather than the last. Historically this has not been well-defined, but the current version of the spec (RFC 7231) tries, suggesting

Authors of specifications defining new header fields are advised to consider documenting:

• Whether the field is a single value or whether it can be a list (delimited by commas; see Section 3.2 of [RFC7230]).

  If it does not use the list syntax, document how to treat messages where the field occurs multiple times (a sensible default would be to ignore the field, but this might not always be the right choice).

Unfortunately, that same spec--where "Content-Type" is defined (section 3.1.1.5)--doesn't follow it's own advice that I can see. The closest is that one statement suggesting a "sensible default" that "might not always be the right choice". The spec is clear that Content-Type is a single-value field, though.

About a year before this bug was filed Chrome and Firefox appeared to agree and take the last valid header, but it's messy:
https://github.com/whatwg/mimesniff/issues/30#issuecomment-333821690

The current version of the WHATWG Fetch spec was updated to be clear that the last (good) value should be used, based on web-compatibility in practice. That would mean interpreting the previous site behavior as image/apng was correct:
https://fetch.spec.whatwg.org/#example-extract-a-mime-type