I noticed that for the version 0.9.x series there is no more ReadTimeout fixed value in the backend Server(former ReadTimeout fixed value it’s commented) and Go http.server doesn’t set a default value if nothing is set for http.Server creation. This means that now there is no limit for how long the proxied request could take before get a response?
I ask because I have an issue with that ReadTimeout value in the past that cause me to build Caddy with a ReadTimeout higher value.
That value has been commented since before 0.9; it’s just a TODO to see if we ever wanted to make those configurable; probably could remove those lines…
The issue with setting values on the Server is that the value from multiple sites will have to be reduced to a single value.
That could be configured using a directive for the server block to allow you to use multiple values if supplied with a default to 0 so http.Server could ignore it. But my question was about that if now there is no limit? so I could use the newest Caddy release without suffer from timeouts for long running requests in certain cases?
What I mean is that you may have multiple site blocks in the Caddyfile but they all share the same http.Server, which means that if they have different ReadTimeout settings, we somehow need to choose one from many.
We do not set a limit, so it uses the default value (I think it is just 0).
Thanks for the info and confirmation!!.
For the multiple site blocks sharing the same http.Server I just though that Caddy were creating one http.Server per every subdomain/domain, backend proxied or site block to be served
Nope, one http.Server needs one net.Listener and we can only open one listener on each address. So we have to combine the sites.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.