Hi, Great, thanks for this. Will "option http-no-delay" be required to activate this particular tweak or is that general advice? We'll certainly mention it in our reverse proxy documentation either way.
B. > On 28 Jun 2023, at 04:44, Willy Tarreau <w...@1wt.eu> wrote: > > Hi Robert, > > On Tue, Jun 27, 2023 at 01:19:20PM +0100, Robert Newson wrote: >> Hi, >> >> i'm happy to confirm the two patches combined address the symptom I reported >> at the start of the thread. I applied them to haproxy.git master after >> confirming that the problem occurred there for a realistic setup (couchdb >> with HAProxy in front configured to do compression). > > Excellent, thanks! I'll merge them both to the libslz project and to > haproxy. > >> The CouchDB project are considering adding a WebSocket option for this >> endpoint in light of the re-realisation that we've been living in HTTP sin >> this whole time. > > Yes that would be nice indeed! I don't know if you could benefit from > this, but in addition with websocket you'd get fully interactive and > bidirectional communication, which may allow the client to send extra > requests or interrupt the processing etc. Also WS will work both over > HTTP/1 and HTTP/2 and might permit to coalesce multiple connections > into a single one with multiple streams if there's any benefit in doing > this. > >> Your patches are most welcome as they mean users can keep doing what they've >> always been doing and can upgrade HAProxy without having to make any change. > > Yeah, I'll ensure we can backport them so that it continues to work > transparently. Please just remind your users that they should be using > "option http-no-delay" for what they're doing. It's very possible it > will improve latency for them even on older versions, and may avoid > similar issues in the future. > >> In the long term CouchDB will work towards providing an alternative method >> that doesn't depend on the timely delivery of partial messages. >> >> Thank you again for your efforts, it is very much appreciated. > > You're welcome. It's always a pleasure to be able to improve the code > base to cover some real-world limitations, especially when this grants > more time to address these limitations cleanly for the long term. It's > always better than stacking ugly emergency workarounds :-) > > Cheers, > Willy
