Hi Lukas, On Mon, Sep 24, 2018 at 01:46:57AM +0200, Lukas Tribus wrote: > Hello, > > > On Fri, 21 Sep 2018 at 15:45, Pierre Cheynier <[email protected]> wrote: > > Let me know if you see something obvious here, or if this is candidate to a > > bug. > > > > We have a service using SSE through text/event-stream content-type. > > > > In HTTP/1.1 we have a normal stream as expected : > > < HTTP/1.1 200 OK > > < Content-Type: text/event-stream > > data: {"a": "b"} > > > > data: {"a": "b"} > > > > data: {"a": "b"} > > (...) > > > > HAProxy on its side adds the `Connection: close` header. > > > > When adding 'alpn h2,http/1.1' to the bind directive, we observe the > > following: after the first 200OK, the connection is closed by haproxy both > > on server and client side by sending a FIN/ACK. > > The backend server is not providing neither Content-Length, nor using > chunked Transfer-Encoding in the response. This makes using keep-alive > impossible, regardless of the HTTP version. > > Theoretically the frontend connection could be kept up in this > situation as far as I can tell, but that is an optimization that will > require more work in haproxy (as the http layer and error handling > becomes more http version agnostic - currently many transaction based > problems affect the entire H2 mux).
In fact not, it should work as we close streams and not connections. So I conclude we have a bug there that I need to explore further. Pierre, it would be interesting to know if the connection ends up on a timeout or after the server closes. If it's a timeout it might be expected that it's the same on both sides and that we simply close when it strikes. If the server closed, we should only close the stream (empty DATA frame with ES=1) but not the connection. It is possible that we do this and face a protocol error later leading to the connection being closed, so that's why I'm interested in the exact sequence. Cheers, Willy
