I don't know for sure what the root cause is. My working theory is that it's due to one of these: • ring-core 1.15.x now attempts to add the Content-Length header automatically to responses it thinks it can know the length of. Previously, it never bothered (I think) unless you explicitly added it yourself. It's possible that the Content-Length header is calculated by the middleware before the response is gzipped, if the request includes the

Accept-Encoding: gzip

header. If so, then the

Content-Length

would be wrong, the receiver is waiting for more content that doesn't exist because it's been gzipped, and times out eventually. I think generally around https://github.com/OpenVoxProject/trapperkeeper-webserver-jetty10/blob/0fdc33f13cf[…]rc/puppetlabs/trapperkeeper/services/webserver/jetty10_core.clj we're wrapping the ring handler, but I'm not really familiar with all the machinery there. It would be broken for ring to apply

Content-Length

when it knows the response is going to be gzipped, but it isn't clear to me if we're gzipping it ourselves outside of ring's awareness or not. Kinda seems like we are with https://github.com/OpenVoxProject/trapperkeeper-webserver-jetty10/blob/0fdc33f13cf[…]rc/puppetlabs/trapperkeeper/services/webserver/jetty10_core.clj, but I don't have a clear view of the whole chain of events in crafting the response. • Another thing it could be related to is https://github.com/ring-clojure/ring/issues/519 and the change in https://github.com/ring-clojure/ring/commit/a27b98f9640ea1e6a2524410a0bac7b30cdea316. This specifically changes the behavior of how ring flushes data, done in relation to how Jetty handles it, and given that 1.14/1.15 is targeting Jetty 12, I suspect it just was never tested with Jetty 10 and there's some bad interaction there. • It could be also be both of the above, or neither of the above.