HTTP status code -1 mean?

I am using openshift which contains Haproxy2.0 as route LB, recently, I got several 502 from frontend nginx. When I dig into the Haproxy log, I found:
worker-0 haproxy[355]:
...:54628 [23/Nov/2021:07:14:34.892] public be_http:des:gateway-esb-http-route/pod:gateway-esb-http-647c66b9cf-5md4w:gateway-esb-http-server::...:8081 0/0/0/-1/0 -1 0 - - SDVN 13/3/1/0/0 0/0 “POST /esb/api HTTP/1.0”

for sensitive reasons, I hid the IP information. My question is, what does the HTTP status code “-1” mean? I didn’t find any useful information in http://www.haproxy.org/download/2.0/doc/configuration.txt. From the log, the only thing I can get is the server closed the connection, but how?

Hello,

I assume you are using default http log format. The important info are the timers. You can see TR (‘0/0/0/-1/0’) is -1. The doc is clear with this :

  • “TR” is the total time in milliseconds spent waiting for a full HTTP request from the client (not counting body) after the first byte was received. It can be “-1” if the connection was aborted before a complete request could be received or a bad request was received. It should always be very small because a request generally fits in one single packet. Large times here generally indicate network issues between the client and haproxy or requests being typed by hand. See section 8.4 “Timing Events” for more details.

So it seems like an incomplete or bad request.

From the TR status, it means the connection was aborted before a complete request could be received or a bad request was received, but the terminate code SDVN means
“The connection to the server died with an error during the data
transfer. This usually means that haproxy has received an RST from
the server or an ICMP message from an intermediate equipment while
exchanging data with the server. This can be caused by a server crash
or by a network issue on an intermediate equipment.”
So what does the log really means? Does it closed by the server or it was a bad request from the frontend?

Turns out the case was caused by duplicated TCP SYN to the backend server, nothing wrong with the Haproxy.