Hi, I underestimated. the heartbeat option was added back in 2009, 14 years ago, but I don't want to fixate on whether we made this mistake long enough ago to justify distorting HAProxy.
The CouchDB dev team are discussing this internally at the moment and I'll update this thread if/when any conclusion comes out of that. It was noted in that discussion that PouchDB (https://pouchdb.com/) does the same thing btw. Given the nature of the endpoint (it could well return large amounts of highly compressible data) we're not keen to disable compression on these responses as the ultimate fix, though that certainly _works_. We could do as little as warn in our documentation that timely delivery of heartbeats is not guaranteed and as much as simply ignore the heartbeat request parameter and proceeding as if it were not set (thus the response is a stream of lots of actual data and then, after a short idle timer expires, it terminates cleanly with an empty chunk). Another thought is we could cause a configurable number of heartbeat chunks to be emitted instead of a single one to overcome any buffering by an intermediary, whether HAProxy or something else. In brief, we have options to ponder besides altering HAProxy in ways that violate both the letter and spirit of HTTP law. On reflection, I don't think HAProxy should attempt to fix this problem, but I thank you for holding that out as an option. B. > On 23 Jun 2023, at 16:08, Willy Tarreau <w...@1wt.eu> wrote: > > Hi Robert, > > On Fri, Jun 23, 2023 at 12:04:14PM +0000, Robert Newson wrote: >> Hi Willy, >> >> thank you for this response. The behaviour in CouchDB is ancient (12 years >> plus, essentially since before the 1.0 release), and yes it is clearly a bit >> naughty, though it has also worked up to this point for us. > > That's exactly the problem with extensions that only work due to the > tolerance of some components, one day they suddenly break on tiny > changes. It's said to learn that it was created 12 years ago because > back then the problems caused by such practices started to be well > known among HTTP implementors. But I know pretty well that it's always > difficult to find information about potential future problems during > the design phase :-/ > >> The reason I raised this here is because it seemed inadvertent given the >> bisect, but I completely accept that this isn't something you should "fix" in >> HAProxy as it is not broken behaviour. You are also of course right that many >> other things could cause the same issue; they just don't happen to in our >> particular setup. > > I perfectly understand. That's also why I said that maybe we should try > to think about an option to systematically flush compressed data, or > preferably to figure if anything in your server's responses could allow > to automatically disable compression. > >> We'll take this onboard and think of next steps. A simple option is to simply >> disable compression on the responses to these requests, since we can easily >> identify which would be affected. All other endpoints, many of which send >> chunked responses, make no assumptions about the timing of the individual >> chunks (just as long as you get them all in the right order). > > OK, that's a good news already. As a side note, keep in mind that chunks > are just an on-wire delimitation at the connection level and have no > meaning for the protocol nor the transported data, and as such they're > not supposed to be forwarded 1-to-1. In practice most intermediaries > will proceed as recommended, which is to advertise the known length of > pending data, so the output data will appear re-chunked to buffer-size > chunks. But of course no reordering is permitted. The real goal of > chunks is only to permit to indicate the end of a body whose initial > size was not known at header time, without closing, That's why usually > chunks are of a whole buffer size. > > Do not hesitate to let us know if the issue prevents users from upgrading > so that we can try together to figure a backportable solution to offer > them a smoother transition. > > Best regards, > Willy
