{
acme_ca https://acme-v02.api.letsencrypt.org/directory
key_type p256
preferred_chains smallest
servers :443 {
protocol {
strict_sni_host
}
}
}
example.com {
tls {
dns cloudflare <key>
}
encode zstd gzip
respond "网站正在建设当中……"
header {
Content-Type "text/plain; charset=utf-8"
}
}
# Refer to the Caddy docs for more information:
# https://caddyserver.com/docs/caddyfile
3. The problem I’m having:
Since the Simplified Chinese environment of Windows works on GBK encoding, if the web page does not declare the encoding, the browser will use GBK encoding by default.
I don’t know how Caddy uses respond, but I use UTF-8 encoding to save Caddyfile. So Caddy should respond through UTF-8.
This caused me to display garbled characters when I visited the Chinese webpage.
I can only add the header manually to declare the encoding used. Could Caddy add an automatic declaration mechanism?
Please don’t forget to use a volume for the /data directory, otherwise you risk losing your certs and keys, and potentially hit rate limits if Caddy gets stuck in a restart loop. See the docs on Docker about this.
I also don’t see a mount for /etc/caddy/Caddyfile here, and I don’t see the Caddyfile being copied in your Dockerfile. How are you making sure Caddy runs from the right config?
Hmm. I can’t replicate the issue, it works for me. I saved the following in a file, UTF-8 encoded (used VS Code to create and save the file)
Then I ran Caddy with this Caddyfile, and used both curl and Firefox to confirm that it looks okay:
Do note that Caddy will not compress/encode responses under a certain size, due to being inefficient/wasteful. By default this minimum is 512 bytes.
I tried copy-pasting that string repeatedly to make it bigger than the minimum, to make sure compression also works, and it does (Firefox shows it received a compressed response).
The situation of Mozilla Firefox is rather dumbfounding. Since it only accepts text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8, Caddy responds 404. Even if I add the header Content-Type "text/html; charset=utf-8", it doesn’t work. It seems that Caddy treats respond as plain by default, so it directly returns 404.
That’s actually not Caddy responding there… Notice there’s no Server: Caddy in the response. I don’t know what server you’re connecting to instead, but… It’s not Caddy.
Other than that, I’m sorry, I don’t think I’ll be much more help because I’ve never even heard of GBK encoding. Encodings aren’t something I ever need to care about as an English speaker, I guess.
That is the problem what I mean. The response design does not take into account the experience of non-ASCII users.
This makes me have to add headers, although it is easy. But this is still a kind of design flaw.