Erroneous error code on wrong configuration


#1

This is happening with, version 1.5.12 2015/05/02. I had no match with the ACL statement, but the error code indicated was 503, with the flags ‘SC’ which in no way indicates that we have a bad ACL statement. Wanted to know if this was addressed/fixed in the later versions ? Or is it worthwhile to put some error codes for these kind of errors ? A lot of time was killed due to this, which could have been prevented had the error code been more informative, or useful.


#2

ACLs can be used in a lot of different ways, like denying request, selecting backends, etc.

I assume the bad ACL statement lead haproxy to switch the traffic to another, maybe the default backend, which had indeed problems explained by the SC flag?

Please share your configuration, as complete as possible and the log of this 503 error (should show the backend and server as well).


#3

So, the acl statement looked like this,
"acl global hdr(host) -i 10.47.4.2, 10.47.4.2:80
use_backend default_backend if global
"
And the error in the log, looked something like this,
"72.20.160.156:52720 [27/Apr/2016:19:05:41.475] frontend frontend/ -1/-1/-1/-1/+0 503 +212 - - SC-- 88/0/0/0/0 0/0 {10.47.4.2||||Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.86 Safari/537.36} {|||} “GET / HTTP/1.1"”

Now the acl statement is not matching anything, and I do not have a default_backend section, so it is not doing anything. But the error log code “SC” is not at all informative, with this regard (like telling that bad acl statement or no backend matched or something).


#4

Gonna need more configuration than that, especially front and backend configs.


#5
frontend my_frontend
    mode http
    maxconn 1000


    option httplog
    option forwardfor header x-e-client

    capture request header Host len 128
    capture request header X-Forwarded-For len 128
    capture request header Content-Length len 16
    capture request header Referer len 4096
    capture request header User-Agent len 128
    capture response header Server len 128
    capture response header Location len 128
    capture response header Content-Length len 16
    acl global hdr(host) -i 10.47.4.2, 10.47.4.2:80
    use_backend my_backend if global

backend my_backend
    mode http
    balance roundrobin

    option forwardfor header x-e-client
    #option prefer-last-server
    option forwardfor header FK-Client-IP
    cookie FKSID prefix indirect nocache
    http-request set-header x-e-id 3.3.3.3
    http-response set-header x-e-id 3.3.3.3


    server 1.1.1.1 1.1.1.1:80 weight 255 maxconn 1000
    server 2.2.2.2 2.2.2.2:80 weight 255 maxconn 1000

Do you need anything else other than these, which might have an effect on the error code which haproxy publishes in the logs ?


#6

Ok, I see what you mean, you would see something like this:

haproxy[6379]: 127.0.0.1:53010 [29/Apr/2016:12:05:40.552] my_frontend my_frontend/<NOSRV> -1/-1/-1/-1/1 503 212 - - SC-- 0/0/0/0/0 0/0 "GET / HTTP/1.1"

With a config as simple as:

frontend my_frontend
    bind :80
    acl global hdr(host) -i blablabla
    use_backend my_backend if global
backend my_backend
    server google www.google.com:80

As you can see from the “NOSRV”, no backend was selected, and the timers indicate that as well.

I agree that SC is confusing, giving that the documentation insists this is a connection failure towards the server, which is clearly wrong in this case.

The behavior is consistent from at least 1.4.0 to current development branch. So there is no fix for this yet. Will have to report this on the mailing list.


#7

Which mailing list do we need to report this at ?


#8

haproxy@formilux.org (no need to subscribe)


#9

Thanks! :slight_smile: