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
