I always get a Bad Request (400) response from Haproxy with this configuration. Here is the frontend :

frontend http-in
    bind *:80
    mode http
    option httplog
    log debug
    acl cm-acl  hdr(host) cm-lab
    acl hue-acl hdr(host) hue-lab
    use_backend  cm if cm-acl
    use_backend  hue if hue-acl

and here the backend :

backend cm
    #server cm lrc1i720.server.lan:7180
    server 01 toto1i720.server.lan:7180 check
    server 02 toto2i721.server.lan:7180 check backup

backend hue
    server 01 toto1i724.server.lan:8888 check
   # server 02 toto2i725.server.lan:8888 check backup

It's working for the "cm" bakend, but not for the "hue" backend. I guess it come from the hue server that is doing a 302 redirection. So I have tried to set directly the target of the url redirection :

    server 01 toto1i724.server.lan:8888/accounts/login/ check

But I still get the 400 error with Bad request. What can I do to allow Haproxy to follow the redirection ? Or is there an other way to do please ?


I hope this is what you're expecting. So here are the log (it's set to debug, but it's absolutly not verbose enough ):

Nov 24 11:17:02 localhost haproxy[71630]: IP.IP.IP.IP:60497 [24/Nov/2017:11:17:02.604] http-in hue/01 2/0/0/4/6 400 652 - - ---- 3/1/0/1/0 0/0 "GET / HTTP/1.1"
Nov 24 11:17:02 localhost haproxy[71630]: IP.IP.IP.IP:60497 [24/Nov/2017:11:17:02.604] http-in hue/01 2/0/0/4/6 400 652 - - ---- 3/1/0/1/0 0/0 "GET / HTTP/1.1"

here is the HTTP query header and response :

# curl -k -v https://hue-int/
* About to connect() to hue-int port 443 (#0)
*   Trying X.X.X.X...
* Connected to hue-int (X.X.X.X) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* skipping SSL peer certificate verification
* SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
* Server certificate:
*       subject: CN=vip-host1-host2.server.lan,E=toto@titi.fr,OU=TEST,O=company,L=VILLE,ST=VILLE,C=FR
*       start date: mai 19 07:15:22 2017 GMT
*       expire date: mai 19 07:15:22 2018 GMT
*       common name: vip-host1-host2.server.lan
*       issuer: CN=vip-host1-host2.server.lan,E=toto@titi.fr,OU=TEST,O=company,L=VILLE,ST=VILLE,C=FR
> GET / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: hue-int
> Accept: */*
< Content-Length: 26
< x-xss-protection: 1; mode=block
< x-content-type-options: nosniff
< Content-Security-Policy: script-src 'self' 'unsafe-inline' 'unsafe-eval' *.google-analytics.com *.doubleclick.net *.mathjax.org data:;img-src 'self' *.google-analytics.com *.doubleclick.net http://*.tile.osm.org *.tile.osm.org *.gstatic.com data:;style-src 'self' 'unsafe-inline';connect-src 'self';child-src 'self' data:;object-src 'none'
< strict-transport-security: max-age=31536000; includeSubDomains
< Vary: Accept-Language
< Content-Language: en-us
< Date: Fri, 24 Nov 2017 10:44:48 GMT
< X-Frame-Options: SAMEORIGIN
< Content-Type: text/html
< audited: False
< Server: apache
* Connection #0 to host hue-int left intact



  • 1
    HAProxy doesn't follow redirects. It returns then to the browser. It's really unclear what you are trying to accomplish, but please show us the log entry for the failed request along with request and response headers. – Michael - sqlbot Nov 3 '17 at 20:31
  • Michael : Thank you, I have updated the question, I hope this is what your expecting. Regards, A. – Antoine Nov 24 '17 at 10:39
  • HAProxy seems to be working fine. This error is coming from the back-end server 01 in the hue backend; as you can see from the response header, Server: apache. You need to review logs on that system to determine what it doesn't like about the incoming request. – Michael - sqlbot Nov 24 '17 at 13:31

@Antoine: You generally get 400 status code if the backend service is not able to recognize an URL. It can be due to several reasons.

1) Request/URL getting purged due to the length.
2) A bad character in the Request/URL.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.