TransWikia.com

How allow Haproxy to follow a redirection?

Server Fault Asked on January 5, 2022

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 ?

EDIT :

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,[email protected],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,[email protected],OU=TEST,O=company,L=VILLE,ST=VILLE,C=FR
> GET / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: hue-int
> Accept: */*
>
< HTTP/1.1 400 BAD REQUEST
< 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

Regards,

A.

One Answer

@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.

Answered by navmarwaha on January 5, 2022

Add your own answers!

Ask a Question

Get help from others!

© 2024 TransWikia.com. All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP