Hi,

On Fri, Jan 11, 2019 at 01:05:15PM +0200, Assen Totin wrote:
> Hi, everybody!
> 
> I'm facing an issue with a somewhat weird/broken client and I'm looking for
> some advise on it.
> 
> The client opens a HTTPS session and sends its request (POST data in my
> case). The HTTPS part is fine. The POST data is small, so it fits into a
> single TCP packet, which arrives with ACK,PSH,FIN flags set. HAProxy
> diligently responds with FIN,ACK and closes the client connection, not
> sending anything to the backend server. It also logs the request as CR--
> which seems proper.
> 
> There is nothing specific in my HAProxy setup in this case, default config
> with a single frontend/backend. I'm on 1.8 series.

It is *not* supposed to happen by default, we're extremely careful about
half-closed requests, and in fact in 1.8, HTTP/2 is translated to HTTP/1
with a close appended just after the request. Are you up to date with your
1.8 version ? Also are you certain your config doesn't contain
"option abortonclose" ? This option exists exactly to cause the behaviour
you're observing.

> I'm aware that sending a FIN on a TLS connection violates the TLS RFC, but
> I suspect that such a client would do the same on a non-TLS connection too.
> It brings me to the question, is there a way to tell HAProxy not to close a
> client connection upon receipt of FIN on the client side if there is an
> unserved HTTP request, but rather keep the client connection half-open
> until the backend responds?

The client connection is half-open in this case because that's how it is
at the transport level. But the request should properly be served regardless
of this.

> The issue I'm facing is likely exacerbated  by
> the fact that client sends FIN together with the HTTP request, so there is
> no backend connection yet when HAProxy decides to close the client
> connection.

As I said, it's exactly what is done for requests coming from HTTP/2, so
if it's neither a configuration issue nor a known bug, you may be on a
corner case that hasn't been identified yet.

> Any ideas will he much appreciated. I'm open to testing config
> changes/patches if needed (or even writing one with some guidance).

Great ;-) Please double-check the points above, and share a reduced
config exhibiting the problem.

Thanks!
Willy

Reply via email to