On 12.02.2016 03:29, Dennis Jacobfeuerborn wrote: > Hi, > I've run into a strange phenomenon and I'm not sure if it's something > I'm doing wrong. > > I have one SSL offloading frontend that receives requests, does > "http-request set-header X-Forwarded-Proto https" and then uses > send-proxy to forward the request to the plain http backend. > > In the plain http frontend there is a check if the X-Forwarded-Proto > header is set to https and if that is *not* the case the client is > redirected to the SSL frontend. > > In the http frontend I added the following two lines: > stick-table type ip size 200k expire 30s store gpc0,http_req_rate(10s) > tcp-request connection track-sc1 src > > The problem I now run into is the following: When I access the site via > http I get an entry in the stick-table and I'm redirected to the SSL > frontend as expected but when I access the SSL frontend directly no > entry gets added. It looks as if the requests that get forwarded using > send-proxy completely bypass the tracking. > > Is this expected? > > I was thinking about moving the tracking to the SSL frontend but that > uses nbproc > 1 and I know that this causes issues with stick-tables and > peers so I'm hoping there is some other way I can get all requests > properly tracked.
After sending the message I thought about this some more and then it suddenly became obvious: "tcp-request connection" only sees the tcp connections and since I'm using the abstract namespace sockets for the send-proxy call the plain http frontend obviously never gets to see the actual tcp connections from the SSL frontend. So the fix was to replace "tcp-request connection" with "tcp-request content". The question now is if that has any negative impact on performance? If not why would one not always use the "content" variant since that seems to be more powerful than its "connection" sibling? Regards, Dennis
