1883037 - Handling of comma separated Content-Type and X-Content-Type-Options: nosniff

Status: UNCONFIRMED

(Core :: Networking: HTTP, defect, P3)

Description

[indocomsoft]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:124.0) Gecko/20100101 Firefox/124.0

Steps to reproduce:

Visit https://5000.taiwan.net.tw/index_en.html

Actual results:

CSS stylesheets are not loaded.
The server sets HTTP header X-Content-Type-Options: nosniff.
The content type HTTP header is Content-Type: text/css,text/html; charset=utf-8.
Firefox saw text/html and refuses to load the CSS files.

Expected results:

CSS stylesheets are loaded because the content type HTTP header does contain text/css. This works fine on Chrome and Safari (macOS)

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::CSS Parsing and Computation' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Manuel Bucher [:manuel]]

https://www.rfc-editor.org/rfc/rfc9110#field.content-type

Although Content-Type is defined as a singleton field, it is sometimes incorrectly generated multiple times, resulting in a combined field value that appears to be a list. Recipients often attempt to handle this error by using the last syntactically valid member of the list, leading to potential interoperability and security issues if different implementations have different error handling behaviors.

Returning multiple content type values is not spec compliant.

Comment 3

[Sunil Mayya]

The problem here is that we are assigning the MIME's essence as text/html as opposed to text/css.

We should update our parsing logic here to match what Safari/Chrome is doing.