Search code examples
haproxy

What are HAProxy's http-request and http-response for?

I'm not quite clear about the options http-request or http-response in HAProxy configuration. Many of the parms seem to be used for modification of http request and response but what I found is it can be done using the regular option as well

What's the difference between

http-request set-src hdr(x-forwarded-for)  #and
option forwardfor

Also what's the difference between:

connect timeout 5000
client timeout 5000
server timeout 5000        #And

http-request timeout 5000

I'm new to haproxy and from the documentation is written from configuration parameter perspective (like a api reference) instead of a use-case perspective (like a user-guide).

So If I asked an absurd question please do not mind and answer kindly. Thanks

Solution

  • What's the difference?

    These first two are sort of opposites.

    Configure HAProxy to use the contents of the X-Forward-For header to establish its internal concept of the source address of the request, instead of the actual IP address initiating the inbound connection:

    http-request set-src hdr(x-forwarded-for)

    Take the IP address of the inbound connection and add an X-Forwarded-For header for the benefit of downstream servers:

    option forwardfor

    Also what's the difference?

    Let's take this one backwards.

    First, this isn't valid in any version that I'm aware of:

    http-request timeout 5000

    I believe you mean this...

    timeout http-request 5000

    ...which sets the timeout for the client to send complete, valid HTTP headers and an extra \r\n signifying end of headers. This timer doesn't usually apply to the body, if there is one -- only the request headers. If this timer fires, the transaction is aborted, a 408 Request Timeout is returned, and the client connection is forcibly closed. This timer stops once complete request headers have been received.

    By default, this timeout only applies to the header part of the request, and not to any data. As soon as the empty line is received, this timeout is not used anymore.

    http://cbonte.github.io/haproxy-dconv/1.6/configuration.html#4-timeout%20http-request

    Note: http-request is something entirely different, and is used for manipulating the request during the request processing phase of the transaction lifecycle, before the request is sent to a back-end server.

    Continuing, these aren't actually valid, either.

    connect timeout 5000
client timeout 5000
server timeout 5000

    It seems you've reversed the keywords. I believe you're thinking of these:

    timeout connect 5000

    That's the maximum time to wait for the back-end to accept our TCP connection by completing its share of the 3-way handshake. It has no correlation with timeout http-request, which is only timing the client sending the initial request. If this timer fires, the proxy will abort the transaction and return 503 Service Unavailable.

    timeout client 5000

    This one does overlap with timeout http-request, but not completely. If this timer is shorter than timeout http-request, the latter can never fire. This timer applies any time the server is expecting data from the client. The transaction aborts if this timer fires. I believe if this happens, the proxy just closes the connection.

    timeout server 5000

    This is time spent waiting for the server to send data. It also has no overlap with timeout http-request, since that window has already closed before this timer starts running. If we are waiting for the server to send data, and it is idle for this long, the transaction is aborted, a 504 Gateway Timeout error is by HAProxy, and the client connection is closed.

    So, as you can see, the overlap here is actually pretty minimal between these three and timeout http-request.

    You didn't really ask, but you'll find significant overlap between things like http-response set-header and rsp[i]rep, and http-request set-header and req[i]rep. The [req|rsp][i]rep keywords represent older functionality that is maintained for compatibility but largely obsoleted by the newer capabilities that have been introduced, and again, there's not as much overlap as there likely appears at first glance because the newer capabilities can do substantially more than the old.

    I'm new to haproxy and from the documentation is written from configuration parameter perspective (like a api reference) instead of a use-case perspective (like a user-guide).

    That seems like a fair point.