Basically the main issue is that you actually change the request instead
of redirecting.
You should use a 302 redirect full response for the request that will
result the client accessing the 192.168.1.145:8089 server by itself.
ELiezer
On 08/19/2014 03:07 AM, agent_js03 wrote:
ICAP/1.0 200 OK
Date: Mon, 18 Aug 2014 23:15:42 GMT
ISTag: i16FID6HcIdc9AbGie8d03f1Ij5dejcj
Encapsulated: req-hdr=0, null-body=545
Server: BaseICAP/1.0 Python/2.7.8
GET
http://192.168.1.145:8089/blockpage.php?category=Banned+URL+Regex&criteria=dog.%2Abiscuits
HTTP/1.1
via: 1.1 localhost (squid/3.2.11)
accept-language: en-US,en;q=0.5
accept-encoding: gzip, deflate
x-forwarded-for: 127.0.0.1
accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
user-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:30.0) Gecko/20100101
Firefox/30.0
host: search.yahoo.com
cookie: B=c3lrj0t9v516p&b=3&s=90; HP=1
cache-control: max-age=0
surrogate-capability: localhost="Surrogate/1.0 ESI/1.0"
The page 192.168.1.145:8089 is the local php blockpage. The banned URL regex
criteria is the regex dog.*biscuits.
I am not sure what is going on. Here is what works so far: if I do a reqmod
on a non-SSL page and it blocks, then it goes through OK. If I do a respmod
on either a non-SSL page or an SSL-page and feed the content back, it goes
through OK and I see the blockpage. The only thing that doesn't work is if I
do a reqmod and it tries to redirect me to the blockpage. And this only
happens with transparent proxying. When I have my server set up for a manual
proxy, it works fine; the blockpage shows up OK. Why would it behave
differently running as a transparent proxy?
