V2: how to handle MIME information?

I have the situation that with v2 the “content type” header is missing for some files like fonts or javascript files. I found a closed issue on this topic that states that the information should be provided by the MIME table from the system.

Using the caddy/caddy:alpine docker image I tried to install mailcap which provided me that missing file. Nevertheless still no “content type” header is send.

Do I really have to set the header manually using the header directive or is there an other solution?

According to the mime package library documentation, you can supplement the system’s mime table by editing any of these files:

/etc/mime.types
/etc/apache2/mime.types
/etc/apache/mime.types

mime package - mime - pkg.go.dev
How do I change the MIME type for a file? - Ask Ubuntu

1 Like

After installing the package ‘mailcap’ I had already searched for two of the file types where caddy lacks in sending the appropriate content type header:

bash-5.0# grep -E "(woff|javascript)" /etc/mime.types
# application/font-woff deprecated in favor of font/woff
application/javascript				js
font/woff					woff
font/woff2					woff2

I don’t understand why I can’t get it to work. What am I missing?

I’m not sure how that all works (or doesn’t work) tbh. does the OS cache that information or something? Have you tried rebooting?

I am using the caddy/caddy:alpine docker image and installing ‘mailcap’ during docker build. So the file is available from the start of the container.
simplified Dockerfile:
FROM caddy/caddy:alpine
RUN apk --no-cache --update add mailcap

I still wonder why anybody else (using docker) has this problem serving JS files…

I retestet with both container images:

  • caddy:latest
  • caddy/caddy:alpine

and with an empty JS file I do get the correct header; even without installing ‘mailcap’:
Content-Type: text/javascript; charset=utf-8

So this does not seem to be related to caddy. I do appologize. But strangely enough, I only changed the caddy version from v1 to v2 inside my Dockerfile

2 Likes

Thanks for investigating! It will probably help others in the community. Please continue to follow-up if you discover anything else!

Thanks for reporting this @tribor, and for the suggested fix!

While you did get a .js file to work correctly, that was only because the Go standard library supports that particular MIME type natively. For fonts, however, it’ll only work with mailcap installed.

I’ve added it as part of Adding the mailcap package by hairyhenderson · Pull Request #70 · caddyserver/caddy-docker · GitHub, and it’ll appear in the official caddy images soon!

Side-note: I see that you tried both caddy:latest and caddy/caddy:alpine - those two images are actually exactly the same, but you should be switching to using the official caddy images instead!

2 Likes

Well, actually I discovered that my real problem was a missing file_server directive in my Caddyfile. The result without that missing line is that files are served as:

  • empty files
  • HTTP/1.1 200 OK
  • No Content-Type

The console of my browser warned me that the file

was loaded although its MIME type (“”) is not a valid MIME type for JavaScript.

which led me to go in the wrong direction in the first place assuming it was a missing mime type issue. I just never noticed the file was empty the whole time!

I would have expected a status code other than 200 in this case when using curl in my example. Nevertheless the log output from caddy states correctly:

“status”: 0

The file server is the handler that would respond with a status code other than 200 if it couldn’t find a file.

If there’s no handler, the response is empty/default. Some clients, if they receive an empty response / no status code, they’ll assume 200.

This topic was automatically closed after 180 days. New replies are no longer allowed.