1872503 - Font loading seems to rely on server returning correct Content-Type

Status: RESOLVED INVALID

(Core :: DOM: CSS Object Model, enhancement)

Description

[Master ? [:masterquestionable]]

    Font loading (via "@font-face" or `<link as="font">`) seems to rely on the server returning correct Content-Type response header: outright skipped loading without so.
    The behavior is likely undesirable.

    See also:
    https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face/src#format

    Haven't tested the JavaScript FontFace API [ https://developer.mozilla.org/en-US/docs/Web/API/FontFace ].
    Expected identical behavior.

Comment 1

[Master ? [:masterquestionable]]

    Potentially invalid.
    What exactly failed was loading font from "localhost".

    Related JavaScript:
[[
    document.body.appendChild( document.createRange().createContextualFragment( '<pre style="font-family: NotoSansMono-Regular">1234567890</pre><style> @font-face { font-family: "NotoSansMono-Regular"; src: url( "http://localhost:8080/NotoSansMono-Regular.ttf" ); } </style>' ) );
]]
    Remote link: https://notofonts.github.io/latin-greek-cyrillic/fonts/NotoSansMono/hinted/ttf/NotoSansMono-Regular.ttf

    Unlikely related with HTTPS-Only Mode: On/Off seemingly no difference.
    Irrelevant with CSP, CORS.

Comment 2

[Tom S]

The MIME type of fonts being enforced is good and desirable, because it prevents unexpected files from being interpreted as fonts.

Comment 3

[Master ? [:masterquestionable]]

    Such check should probably be performed on client-side, after downloading the file.
    Rather than outright terminate connection after sensing the unexpected Content-Type.

    Depending on the response Content-Type to alter browsing experience is acceptable practice. (e.g. the very HTML with "text/html" or "text/plain")
    But for better compatibility and extensibility, certain checks don't have to (and shouldn't) rely on which.

Comment 5

[Daniel Veditz [:dveditz]]

The opposite is true: browsers have historically gotten into all kinds of security and compatibility issues when they second-guess the content-type and try to determine the type on their own ("sniffing"). Microsoft introduced a "nosniff" header servers could use with IE 8 in 2008, and it was broadly pushed by web server security folks soon after. Here, for example, is a post from 2012
https://blog.fox-it.com/2012/05/08/mime-sniffing-feature-or-vulnerability/

Browsers are tightening where and when we can without breaking too much historical content. It's much easier to make sure your one server is sending explicitly correct information than to test that all the browsers out there do the right thing with vague and incorrect data.

Comment 6

[Master ? [:masterquestionable]]

    That is for their broken implementation, not the design.
    Some breakages are unnecessary and avoidable.