No Content-Type when serving .ico files

[tuyuritio]

Describe the bug

When I try to access favicon.ico via a browser, the browser prompts to download the file instead of displaying it.

Using curl, I found that the response has an empty Content-Type header.

This issue is not limited to favicon.ico—it happens with any .ico file.

Some third-party tools may rely on the Content-Type header to correctly identify and handle icon files. The absence of this header can cause issues or unexpected behavior in those cases.

Reproduction

1. Create a minimal project using npx sv create.
2. Download the icon from GitHub for testing.
3. Place favicon.ico in the static directory.
4. Add <link rel="shortcut icon" type="image/x-icon" href="%sveltekit.assets%/favicon.ico" /> to app.html.
5. Run the project and execute curl -I http://localhost:5173/favicon.ico.
6. The response returns an empty Content-Type.
7. Rename favicon.ico to github.ico.
8. Repeat steps 4 and 5. The result is the same.

Logs

`curl -I http://localhost:5173/favicon.ico`:


HTTP/1.1 200 OK
access-control-allow-origin: *
Content-Length: 6518
Content-Type:
Last-Modified: Tue, 29 Apr 2025 19:59:46 GMT
ETag: W/"6518-1745956786944"
Cache-Control: no-cache
...


`curl -I https://github.com/favicon.ico`:


HTTP/1.1 200 Connection established

HTTP/2 200
date: Tue, 29 Apr 2025 20:20:34 GMT
content-type: image/x-icon
last-modified: Tue, 29 Apr 2025 19:23:06 GMT
etag: W/"6811271a-1976"
expires: Fri, 27 Apr 2035 20:20:34 GMT
cache-control: max-age=315360000
vary: Accept-Encoding, Accept, X-Requested-With
server: github.com
...


`file favicon.ico`:


favicon.ico: MS Windows icon resource - 2 icons, 16x16, 32 bits/pixel, 32x32, 32 bits/pixel

System Info

System:
    OS: Windows 11 10.0.26100
    CPU: (16) x64 AMD Ryzen 7 7840HS w/ Radeon 780M Graphics
    Memory: 15.50 GB / 31.28 GB
  Binaries:
    Node: 23.10.0 - C:\Program Files\nodejs\node.EXE
    npm: 11.2.0 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Edge: Chromium (134.0.3124.68)
  npmPackages:
    @sveltejs/adapter-auto: ^6.0.0 => 6.0.0
    @sveltejs/kit: ^2.20.7 => 2.20.7
    @sveltejs/vite-plugin-svelte: ^5.0.3 => 5.0.3
    svelte: ^5.28.2 => 5.28.2
    vite: ^6.3.3 => 6.3.3

Severity

annoyance

Additional Information

No response

[Conduitry]

I believe this file would be getting served by https://github.com/lukeed/sirv which uses https://github.com/lukeed/mrmime for its MIME lookups - which doesn't appear to have .ico in it. It looks like https://github.com/jshttp/mime-db does have .ico. @lukeed Do you know why that one wouldn't be coming through in mrmime?

FWIW, another competing MIME type for this file extension looks to be image/vnd.microsoft.icon and I don't know what the pros and cons of using that vs image/x-icon would be.

[lukeed]

All of the experimental (x-) and vendor-specific (vnd.) values are dropped in mrmime. In this case, .ico has one of each & no stable fallback.

A custom .ico definition can be added & sirv will pick it up (assuming dependency chain reuse)

[Conduitry]

Thanks! Sorry, I had missed that note in mrmime's readme about dropping those.

We should take a closer look at which environments are affected, besides dev/preview and the Node adapter. We might have to solve this in multiple places. (I'm guessing adapter runtimes that aren't based on Node won't be affected by this - and that we don't really have a way to influence those Content-type headers anyway, either.)

For adapters that are currently bundled (which might be all of the relevant ones?), we can add a new direct dependency from the adapter runtime to mrmime and be certain that the user won't end up with two copies, causing sirv to not pick it up. I'm not sure what's the best way to ensure that there's only one instance of mrmime in cases where we're not bundling sirv.