Content-type missing charset info

1. Caddy version (caddy version):

v2.0.0 h1:pQSaIJGFluFvu8KDGDODV8u4/QRED/OPyIR+MWYYse8=

2. How I run Caddy:

Using Docker

FROM caddy:2.0.0

a. System environment:


b. Command:

Using curl to get a json file stored in my document root

curl -v

c. Service/unit/compose file:

FROM caddy:2.0.0

COPY Caddyfile /etc/caddy/Caddyfile
COPY index.html /srv/index.html
RUN caddy validate --config /etc/caddy/Caddyfile

d. My complete Caddyfile or JSON config: {
    # Define Customer IP ranges
    @memyself {
        # Of course not the real IP
    # Define actions for customers
    handle @memyself {
        file_server {
            root /var/www
    # Default: Redirect to my Main Page
    handle {
        redir *

3. The problem I’m having:

I have a json file in UTF-8 on that server which is returned to me like this:

$ curl -v > x
*   Trying
* Connected to ( port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
} [230 bytes data]
* TLSv1.2 (IN), TLS handshake, Server hello (2):
{ [64 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [2372 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [115 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [37 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
{ [1 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / ECDHE-ECDSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject:
*  start date: Jul 11 12:15:35 2020 GMT
*  expire date: Oct  9 12:15:35 2020 GMT
*  subjectAltName: host "" matched cert's ""
*  issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7fa67780d800)
> GET /jsonfile.json HTTP/2
> Host:
> User-Agent: curl/7.54.0
> Accept: */*
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 200 
< accept-ranges: bytes
< content-type: application/json
< etag: "qe4ckx4ownr"
< last-modified: Mon, 27 Jul 2020 08:22:09 GMT
< server: Caddy
< content-length: 7880535
< date: Mon, 27 Jul 2020 10:28:54 GMT
{ [5886 bytes data]

4. Error messages and/or full log output:

No error message, but I get

content-type: application/json

But would expect

content-type: application/json; charset=UTF-8

5. What I already tried:

Checked issues in the forum and just found some explaining stuff about “mime” which I couldn’t make use of as I did not find any documentation about it. Putting it into the Caddyfile nonetheless resulted in errors:

{"level":"info","ts":1595845120.982867,"msg":"using provided configuration","config_file":"/etc/caddy/Caddyfile","config_adapter":""}
validate: adapting config using caddyfile: /etc/caddy/Caddyfile:12: unrecognized directive: mime

6. Links to relevant resources:

Please upgrade to the latest version, i.e. 2.1.1 which has some important fixes. If I remember correctly, we added the mailcap package to the docker image since that version.

Did so. Didn’t change anything.

Could you please tell me how the mailcap package can help me?

Ah, I think I sorta misunderstood the issue. I apologize for reading too quickly. Anyways, mailcap is “mail capability”, it provides the MIME type lookup table that the Go standard lib uses. At one point, it was missing from the docker image so some users were running into issues with content types.

Your question is different in that it relates more specifically to the charset. As an aside, I’ve always understood that as being optional. Where is that causing issues for you exactly, out of curiosity?

One fix would be to override the header if the request is for a .json file:

@isJson path *.json
header @isJson Content-Type "content-type: application/json; charset=UTF-8"

T.b.h. In the meantime I learned that it is no issue at all. The issue lay in a “double encoding” I did when saving the downloaded file. So my issue is solved now, but your last reply is very helpful as it shows me how to set the header based on file extension. I couldn’t figure that out as the documentation (to me) seems very unstructured and/or incomplete.

Small correction. It should be

@isJson path *.json
header @isJson Content-Type "application/json; charset=UTF-8"

Ah yep, my mistake, bad copy-paste while on my phone :smile:

Glad you figured out the issue.

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