Challenge 1: A Font File Served as application/octet-stream — Solution Walkthrough

What happens:

Most browsers will refuse to use the font file as a font at all. A
browser loading a webpage's CSS expects any @font-face resource it
fetches to arrive with a font-appropriate MIME type (something like
font/woff2). When the server instead sends back
application/octet-stream, the browser has no reliable way to confirm
the bytes it received are actually the font type it expected, and
most browsers will simply fail to apply the custom font — falling
back to a default system font — rather than attempting to guess and
render it anyway.

Why this happens:

Per this chapter, an extension with no matching MIME type entry falls
back to a generic type, application/octet-stream, which normally
signals "an arbitrary binary file, download this rather than
interpreting it." A browser fetching this file as part of a page's own
CSS (rather than via a direct top-level navigation) doesn't get an
actual download prompt in this case — it simply treats the resource as
unusable for its intended purpose (rendering as a font), since the
declared type doesn't match what a font resource is expected to look
like.

The fix:

Add a MIME type mapping for the .woff2 extension on the server (an
AddType-style entry on Apache, a types {} entry on Nginx, or the
equivalent MIME Types config on IIS) so the server reports the correct
font/woff2 type instead of falling back to the generic default.

WHY THIS WORKS AS AN ANSWER
------------------------------
This exercise applies this chapter's own "unmapped extension falls
back to application/octet-stream" point to a concrete, realistic
asset type (a web font) rather than only the chapter's own named
example (a stylesheet), showing the same underlying principle applies
broadly to any static asset type the server doesn't have a MIME
mapping for.