adapter_modifying does not modify bing.com

Please disable Squid disk and memory caches. Use wget, curl, or a similar single-request command-line tool. Do you see the expected adaptation?

My conf file for squid cache is already disabled:
coredump_dir deny all
cache deny all
but I still don't see the adapter working on bing.com.

What tool do you use to access bing.com during this test?

I'm using an extension for chrome named, SwitchyOmega.

For initial tests, please use wget, curl, or a similar single-request command-line tool. Do you see the expected adaptation?

Hi Alex,
We've tried curl and wget:
[my-centos ~]# curl -x http://10.xxx.xxx.xxx:3128 -L http://www.bing.com
[my-centos ~]# wget http://www.bing.com -e use_proxy=yes -e http_proxy=10.xxx.xxx.xxx:3128
[my-centos ~]# ...
</body> are both just modified as expected.

However, if we try with pytho2.7:
>>> import requests
>>> requests.get('http://www.bing.com', proxies={'http': '10.xxx.xxx.xxx:3128'}).text
...
</body> is NOT modified as expected.
We've check /var/logs/cache.log, the request is surely passed the proxy.

Any ideas why this happened?

> Any ideas why this happened?

Compare the actual HTTP response headers received by Squid in a wget and python tests. Perhaps the response for the python client was gzip-encoded because the python client claims to accept that encoding? If you cannot figure it out, post the complete packet capture (from both Squid sides, in both directions).

I've upload the pcap and final html file to https://drive.google.com/open?id=0B9Z5D1oCUMY5LUI0SDQxdVdQT00

Yes, it is gzip encoding, as I suspected:

Python (response is gzip-encoded):

GET / HTTP/1.1
Accept-Encoding: gzip, deflate
...

HTTP/1.1 200 OK
Content-Length: 44337
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip
...

Curl (plain response without a Content-Encoding header):

GET / HTTP/1.1
Accept: */*
...

HTTP/1.1 200 OK
Content-Length: 120242
Content-Type: text/html; charset=utf-8
...

If you configure Curl to send "Accept-Encoding: gzip, deflate" instead of "Accept: */*", then, I bet, you will get the same compressed response. Compressed responses are very common in real traffic.

The sample modifying adapter does not support compressed content. Production adapters do (or should). For this and other HTML injection caveats please see https://answers.launchpad.net/ecap/+faq/1793