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?
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 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…
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
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.
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!
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: