[squid-users] wccpv2 + follow X-Forwarded-For

I have been trying to get squid 2.5.Stable4 working with the wccpv2
patch and the follow X-Forwarded-For patch. The wccpv2 patch works
great. However, the X-Forwarded-For patch for squid 2.5 doesn't
correctly patch the source. In the end, I want to apply them both, but
I have been trying to get the X-Forwarded-For patch to apply to the
stock squid 2.5 source. I tried looking at the patch file and manually
copying in the changes, altering them as necessary. I looked at the
wccpv2 patch and compared the way it altered configure.in and some of
the other files, I combined the techniques and ended with a patch that
looked like it would do what I wanted. So I enabled the compilation
option --enable-follow-x-forwarded-for and the configure script seemed
to indicate that the patch was in place. I then compiled squid and
tried using the directives that are added by the patch to squid.conf.
The squid executable did not seem to recognize any of the directives.
Since the patch compiled, I assumed I must have done something
incorrectly in the autoconf/automake stuff (configure.in), but I am new
to autoconf/automake, and what I did looked exactly like what was done
in the wccpv2 patch.

I was not able to include the patch in this email because of the 50000 byte
limit of the list.

To provide some more background, I am currently using squid 2.5-Stable4
+ wccpv2 patch + squidguard for content filtering. My intention is to
switch over to a setup that uses dansguardian. I want dansguardian to
receive the request and then forward it to squid. I want to use acls,
delay pools, and squid's logging facilities as I do with my current
setup. In order for that to work, I need squid to look at the
X-Forwarded-For header provided by dansguardian for acls, delay pools,
and logging. I am not sure who to turn to or where to go on the Follow
X-Forwarded-For patch. I have tried to repair Alan's squid 2.5 patch
without much success. If anyone sees a problem in the configure.in for
my patch file, fixing it would probably clear up the issue I am having.
I have looked for other patches and I did manage to find one that
addresses squid logging and X-Forwarded-For. Here is the patch I found:

****************************************************************************
****************************
****************************************************************************
****************************

--- squid-2.5.STABLE1/src/client_side.c Mon Sep 23 07:04:03 2002
+++ squid-2.5.STABLE1/src/client_side.c Wed Feb 5 10:35:45 2003
@@ -85,6 +85,8 @@
 
 #define FAILURE_MODE_TIME 300
 
+#define DANSGUARDIAN_IP_FORWARD
+
 /* Local functions */
 
 static CWCB clientWriteComplete;
@@ -771,6 +773,9 @@
     clientHttpRequest **H;
     ConnStateData *conn = http->conn;
     StoreEntry *e;
+#ifdef DANSGUARDIAN_IP_FORWARD
+ String s;
+#endif
     request_t *request = http->request;
     MemObject *mem = NULL;
     debug(33, 3) ("httpRequestFree: %s\n", storeUrl(http->entry));
@@ -795,6 +800,13 @@
             http->al.http.content_type = strBuf(mem->reply->content_type);
         }
         http->al.cache.caddr = conn->log_addr;
+#ifdef DANSGUARDIAN_IP_FORWARD
+ if (httpHeaderHas(&request->header, HDR_X_FORWARDED_FOR)) {
+ s = httpHeaderGetList(&request->header, HDR_X_FORWARDED_FOR);
+ if (! inet_pton (AF_INET,strBuf(s),&http->al.cache.caddr))
+ http->al.cache.caddr = conn->log_addr;
+ }
+#endif
         http->al.cache.size = http->out.size;
         http->al.cache.code = http->log_type;
         http->al.cache.msec = tvSubMsec(http->start, current_time);

****************************************************************************
****************************
****************************************************************************
****************************

Alan's patch is targeted at becoming a squid feature and uses the
configuration file to enable/disable the feature. A compile in option
is fine for my situation, so I started looking into what changes I would
need to make to the patch above so that acls and delay pools would use
the X-Forwarded-For entry if it was present and valid.

The clientHttpRequest seems to be the data structure that is depended
upon by logging, acls, and delay pools. In the case of logging,
http->al is the AccessLogEntry for the request, the patch simply checks
if the X-Forwarded-For header is present in valid, converts it into an
address and stores it in the AccessLogEntry data structure instead of
conn->log_addr. The function in which this happens is called
httpRequestFree. After examining Alan's patch, acl.c and delay_pools.c
both seem to use http->request->client_addr for both acls and
delay_pools. I don't really have a picture of what exactly is happening
inside of squid in terms of the callback order. If I were to alter the
http->request->client_addr in the function httpRequestFree, would this
change be utilized by acl.c and delay_pools.c? It is possible that acls
and delay_pools have already been checked by the time I get here. Also,
do I need to cbdataLock the data structure to alter it at this point? I
noticed that Alan's patch actually adds a field to request_t in struct.h
for holding the X-Forwarded-For address. Of course, he also adds
additional callbacks from the look of things. My current thoughts are
to find out if modifying the simple patch above in the way I have
described will address logging, delay pools, and acls.

I am very curious as to what mistake I made in my version of Alan's
patch. I believe the problem must be in configure.in since configure
recognizes the option and prints out the message but the code must be
getting excluded by FOLLOW_X_FORWARDED_FOR not being defined. I assume
that since when I run squid -k check it indicates a parseConfig error
and does not recognize Alan's additional directives.

Does anyone have any ideas on addressing either of these two scenarios?
Any help would greatly be appreciated.

Thank you.

Shawn Campbell
Received on Wed Oct 29 2003 - 09:50:56 MST