Way back I asked for older Caddy Caddy timeout options? but wondering what’s changed and improved with Caddy v2 ? I see some settings configurable when Caddy is used as a reverse proxy for transport http reverse_proxy (Caddyfile directive) — Caddy Documentation.
Is there anything equivalent for when Caddy is used as a web server ? Keepalive time outs, buffers, backlogs etc ? Just looking for settings I can play with to see how they change and/or improve web performance 
There’s a handful of timeout knobs you can turn in the JSON:
Many of these aren’t available in the Caddyfile yet, combination of it being somewhat uncommon to need to tweak them (defaults are usually good enough) and not having spent the time designing an ideal way to do it.
cheers some of the documented options like for various timeouts don’t mention a default value for them ?
I think that’s because there aren’t defaults for those.
idle_timeout, for example, has a conditional default, which is documented:
If zero, ReadTimeout is used. If both are zero, there is no timeout.
If we explicitly hard-code defaults into Caddy, I usually make a point to document it. But if I missed any, just ring the bell.
@matt maybe a good idea to at least set some form of defaults for some timeouts for slowris HTTP like DOS attacks ?
So I want to replicate my Nginx client_body_timeout and client_header_timeout values of 10s, in Caddy v2 is this correct way for my HTTPS site = srv1 ?
curl -s localhost:2019/config/ | jq -r '.apps.http.servers.srv1' > srv1.json
curl localhost:2019/config/apps/http/servers/srv1/read_timeout -X POST -H "Content-Type: application/json" -d '"10s"'
curl localhost:2019/config/apps/http/servers/srv1/read_header_timeout -X POST -H "Content-Type: application/json" -d '"10s"'
curl -s localhost:2019/config/ | jq -r '.apps.http.servers.srv1' > srv1-timeouts.json
diff -U20 srv1.json srv1-timeouts.json
--- srv1.json 2020-05-12 15:24:22.665049146 +0000
+++ srv1-timeouts.json 2020-05-12 15:25:03.672282315 +0000
@@ -1,29 +1,31 @@
{
"listen": [
":4444"
],
"logs": {
"logger_names": {
"caddy2.domain.com:4444": "log1"
}
},
+ "read_header_timeout": "10s",
+ "read_timeout": "10s",
"routes": [
{
"handle": [
{
"handler": "subroute",
"routes": [
{
"handle": [
{
"handler": "vars",
"root": "/usr/share/caddy"
},
{
"handler": "headers",
"response": {
"set": {
"X-Powered-By": [
"caddy centminmod"
]
}
and full srv1 JSON config would be
cat srv1-timeouts.json
{
"listen": [
":4444"
],
"logs": {
"logger_names": {
"caddy2.domain.com:4444": "log1"
}
},
"read_header_timeout": "10s",
"read_timeout": "10s",
"routes": [
{
"handle": [
{
"handler": "subroute",
"routes": [
{
"handle": [
{
"handler": "vars",
"root": "/usr/share/caddy"
},
{
"handler": "headers",
"response": {
"set": {
"X-Powered-By": [
"caddy centminmod"
]
}
}
},
{
"handler": "headers",
"response": {
"set": {
"X-Content-Type-Options": [
"nosniff"
]
}
}
},
{
"handler": "headers",
"response": {
"set": {
"X-Xss-Protection": [
"1; mode=block"
]
}
}
},
{
"encodings": {
"gzip": {}
},
"handler": "encode"
},
{
"handler": "file_server",
"hide": [
"/etc/caddy/Caddyfile"
]
}
]
}
]
}
],
"match": [
{
"host": [
"caddy2.domain.com"
]
}
],
"terminal": true
}
],
"tls_connection_policies": [
{
"match": {
"sni": [
"caddy2.domain.com"
]
}
},
{}
]
}
so once I use JSON method, my Caddyfile is obsolete according to API Tutorial — Caddy Documentation
Important note: This should be obvious, but once you use the API to make a change that is not in your original config file, your config file becomes obsolete. There are a few ways to handle this:
Use the --resume of the caddy run command to use the last active config.
Don't mix the use of config files with changes via the API; have one source of truth.
Export Caddy's new configuration with a subsequent GET request (less recommended than the first two options).
does that mean --resume command last active is before the JSON POST change or is with the JSON POST change ?
not entirely clear when last option for exporting caddy’s new configuration does ? it syncs JSON POST change with Caddyfile so I can do Caddyfile changes + retain JSON POST changes ? or Caddyfile changes no longer work and need to do all subsequent site changes via JSON ?
If you load Caddy from a Caddyfile then make changes via the API, the changes you made via the API will be lost unless you use --resume when running it the next time, in which case it will load your last-good config from Caddy’s config storage directory containing an autosave.json file.
Instead, you can use the caddy adapt command to convert your Caddyfile into a JSON config, then make your changes there, and run Caddy from that JSON config.
Thanks for the clarification. Would be nice to have apps/http/servers supported in Caddyfile too though so we didn’t need to do that via JSON
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
FYI for anyone who finds this (since it seems this has been a popular thread), Caddyfile support will probably come in the next release (probably v2.3.0).