On Tue, Apr 08, 2008, Henrik Nordstrom wrote: > > tis 2008-04-08 klockan 14:28 +0800 skrev Adrian Chadd: > > Take 2: includes initial modularisation (untested; I'll test it at home > > this weekend when I get my tproxy box back online) and configure magic > > (with placeholders for tproxy4/freebsd.) > > > > http://www.creative.net.au/diffs/20080408-tproxy-fix-2.diff > > Comments: > > commTransparentRemote needs to move into comm_openex. You can't fit > tproxy4/freebsd in a reasnoable manner otherwise.
Yup, that'd be part of the follow up work. This first cut is to break out what is there; the next commit would be further API tidyups to support TPROXY4 and FreeBSD. > By removing the need_linux_tproxy you just killed the capability to fall > back no non-tproxy connections if we failed to gain the capabilities > needed.. cache.log will now get filled with tons of errors in such > setups., where you earlier only got a single warning about continuing > without tproxy support.. Yes, I have to give that a little more thought. I may keep the global but not call it "linux_tproxy".. > > * pull out the capabilities stuff, removing the last #ifdef LINUX_TPROXY > > from the source > > TPROXY both versions need the special capabilities, and we do not want > to keep these capabilities if TPROXY is not used.. Ok. > > * make sure upstream/peer-forwarded requests aren't thrown to the tproxy > > code. > > Consider a local proxy connecting to a remote proxy. You may want to > still show the actual client IPs to the remote proxy just as you do to > websites.. > > A cache_peer flag controlling this would make sense, probably defaulting > to not spoof the client ip on requests sent to peers.. I read the current code as "don't do that"; its the behaviour I'd like to maintain. We can always add the functionality later. Adrian -- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $25/pm entry-level VPSes w/ capped bandwidth charges available in WA -
