Hi Scott, On Tue, Sep 25, 2012 at 03:43:54PM -0700, Scott Francis wrote: > one question/feature request, and one possible bug. > > first, the bug: > > haproxy is logging to a local syslog process with > > ==== > global > log 127.0.0.1 local5 > ==== > > and syslog listening with: > > ==== > local5.* /var/log/haproxy > ==== > > haproxy.cfg contains the following frontend definition: > ==== > frontend http_proxy > bind *:80 > mode http > option forwardfor > option http-server-close > option http-pretend-keepalive > option httplog > default_backend apache_ui > ==== > > if I add the following two directives to my frontend definition, I get > no log output *at all* (although "haproxy -c" returns success): > ==== > capture request header X-Forwarded-For len 15 > capture cookie openx3_access_token len 63 > ==== > > however, if instead add the following two headers, I get both an > X-Forwarded-For value and a cookie value (presumably the last cookie > specified if there are multiple) in my log output (pipe-delimited > inside braces), along with the rest of the typical output for "option > httplog": > ==== > capture request header X-Forwarded-For len 15 > capture request header Cookie len 63 > ==== > > is this a bug? should haproxy fail to log any output using "capture > request header" and "capture cookie" directives in the same frontend? > it appears to be legal syntax.
There was a bug more or less related to this in 1.5-dev11, what's your version ? The bug was not exactly the same, though log format was changed and possibly disabled in some conditions. > now the question: is there a method to log (as you can see I'm > attempting above) multiple cookies in log output? Right now, either you use "capture cookie" which logs exactly one cookie in both requests and responses (almost useless, was developped to track an application bug which was causing session crossing by sending a wrong cookie in some responses), or you can use "capture request header" and log the full Cookie header, but be careful, this can be large sometimes. > what about arbitrary cookie names? There is no such thing right now, though it should not be terribly difficult to implement since we already have the fetch functions for cookies. > (software devs have stated that > they'd like all cookies sent by the client dumped, even if they're not > ones we're expecting, which means I can't specify the cookie names > ahead of time because I don't know what they might be). Precisely then you need to log the complete cookie header. > in a similar vein, is there a method to log the entirety of the > X-Forwarded-For header as passed in the HTTP request, and not just the > first instance of the last value? I'm a bit shocked by what I found in the doc : "Only the first value of the last occurrence ..." This does not make any sense at all, it's pretty useless. We could capture the first one, the last one, or the whole, but first value of the last occurrence makes no sense at all, it's totally random. And it does not match my experience since I log multiple occurrences at home. I've just checked the code and it captures the full line of the last occurrence of the header. I'll have to fix the doc. So in practice, if your visitors pass through a chain of squids which each set an XFF header, you'll get the whole chain. The only issue you'll get is if some of the last proxies add a line of their own (as haproxy does), in which case you'll only get this line. But quite frankly, this is not common at all. And if you pass through some proxies in your infrastructures, most often they fold them again. However, the maximum header length will still be truncated to 64 bytes (CAPTURE_LEN). If that's not enough, you can change this in include/common/defaults.h (beware of memory usage). I think we should turn this into a global setting now. > We frequently get X-Forwarded-For > headers that have 3-4 comma-separated values, and cannot currently > change the rest of the infrastructure to transparently pass HTTP > requests (multiple L7 proxies involved; no way to avoid multiple > values in X-Forwarded-For, and we'd like to log the entire chain for > forensic purposes). I understand your requirements pretty well, haproxy has grown in exactly similar environments :-) Regards, Willy
