selvi wrote:
Hi Christos,
Thanks for your reply. I am posting the squid-icap server conversation
and also the debug messages here.
Christos Tsantilas wrote:
Hi Selvi,
selvi wrote:
Hello All,
I am in the process of integrating squid-3.0.STABLE1 with Python based
ICAP Server. Here, i am not able to get the response modification.
Is it a custom ICAP server?
I am using the Python based ICAP Server.
ICAP related configurations given are:
icap_enable on
icap_send_client_ip on
icap_service content respmod_precache 0 icap://<IP
Address>:1344/respmod
icap_class class_1 content
icap_access class_1 allow all
I am not seeing any error messages in the ICAP Server side. Squid also
behaves normally except the following message in cache.log
"essential ICAP service is invalidated by reconfigure: icap://<IP
Address>:1344/respmod [down,gone,!opt]". But when i perform some web
access through ICAP enabled squid proxy, empty page is displayed (the
browser displays nothing).
This message means that the squid tried to send an options request to
the ICAP server and the ICAP server answer was not correct (or just did
not like to the squid)
I am suggesting to enable debug for ICAP client in squid3:
debug_options 93,9 0,9
And search in debug messages to see what they say about. You can also
post the debug messages here.
Also grabbing the conversation between squid and ICAP server using
wireshark or similar tool will be helpful...
Regards,
Christos
A snapshot of the conversation between squid and ICAP server is given
below (using tcpdump).
11:04:02.978996 IP squid225.kovaiteam.com.60111 >
squid225.kovaiteam.com.1344: S 2637131307:2637131307(0) win 32767 <mss
16396,sackOK,timestamp 1238745316 0,nop,wscale 8>
E..<..@.@.0
...........@./n+........+.....@....
I...........
FWIW, I have found that output from Wireshark's text-mode program tshark
is better than tcpdump's plaintext output mode since it displays the
results in a handy offset / data bytes format when the '-x' option is
used, like this:
1199742865.861775 192.16.1.240 -> 205.237.115.33 HTTP GET / HTTP/1.0
0000 00 30 48 41 4b a8 00 11 d8 50 cb a3 08 00 45 00 .0HAK....P....E.
0010 02 a3 1c 7c 40 00 40 06 2c ca c0 10 01 f0 cd ed ...|@.@.,.......
0020 73 21 d6 c9 00 50 e9 5e 8a c1 2a 5d 81 3c 80 18 s!...P.^..*].<..
0030 20 86 f1 a4 00 00 01 01 08 0a 1a 13 f9 ec 25 ad .............%.
0040 b7 77 47 45 54 20 2f 20 48 54 54 50 2f 31 2e 30 .wGET / HTTP/1.0
0050 0d 0a 48 6f 73 74 3a 20 77 77 77 2e 70 61 6c 69 ..Host: www.pali
...
I suggest this because I've found that Squid 3's ICAP parser is more
pedantic than Squid 2.6's, and seeing the exact byte values and offsets
has helped me find ICAP protocol violations in the past.
Anyway, I would suspect the "Encapsulated: " line in the ICAP response
below is the root of the problem; as I believe Christos mentioned, the
values must be separated by commas, not just whitespace.
2008/01/05 15:19:41.425| ICAP/ICAPModXact.cc(574) have 428 bytes to
parse [FD 14;RrB/w icapx1]
2008/01/05 15:19:41.425| ICAP/ICAPModXact.cc(575)
ICAP/1.0 200 OK^M
Date: Sat, 05 Jan 2008 09:49:41 GMT^M
Encapsulated: res-hdr=0 res-body=269^M
Server: ICAP-Server-Software/1.0^M
^M
HTTP/1.0 200 OK^M
Content-Length: 29^M
Accept-Ranges: bytes^M
Server: Apache/2.0.52 (Red Hat)^M
Last-Modified: Sat, 05 Jan 2008 07:22:49 GMT^M
Connection: close^M
ETag: "64cce7-1d-442f47e85e440"^M
Connection: close^M
ETag: "64cce7-1d-442f47e85e440"^M
Date: Sat, 05 Jan 2008 09:49:41 GMT^M
Content-Type: text/html; charset=UTF-8^M
^M
<html>
Hello Selvi
</html>
^M
2008/01/05 15:19:41.426| ICAP/ICAPModXact.cc(653) parse ICAP headers
2008/01/05 15:19:41.426| ICAP/ICAPModXact.cc(882) have 428 head bytes
to parse; state: 0
2008/01/05 15:19:41.426| ICAP/ICAPModXact.cc(894) parse success,
consume 128 bytes, return true
2008/01/05 15:19:41.426| ICAPModXact will no longer backup [FD
14;RrBp(1)S(2)/w icapx1]
2008/01/05 15:19:41.426| consumption guards: 00
2008/01/05 15:19:41.426| ICAP/ICAPModXact.cc(383) max virgin
consumption offset=29 acts 00 consumed=0 from [0<=29<=29 29+2018
pipe0x6000000000451288 cons0x6000000000459768]
2008/01/05 15:19:41.426| ICAP/ICAPModXact.cc(395) consuming 29 out of
29 virgin body bytes
2008/01/05 15:19:41.426| ICAP/ICAPModXact.cc(567) will stop consuming
[FD 14;Rrp(1)S(2)/w icapx1]
2008/01/05 15:19:41.426| ICAP/ICAPModXact.cc(658) parse HTTP headers
2008/01/05 15:19:41.426| ICAP/ICAPModXact.cc(882) have 300 head bytes
to parse; state: 1
2008/01/05 15:19:41.426| ICAP/ICAPModXact.cc(894) parse success,
consume 269 bytes, return true
2008/01/05 15:19:41.426| ICAP/ICAPModXact.cc(926) not expecting a body
This doesn't look good -- I would suspect that the ICAP parser didn't
find the res-body value in the Encapsulated: header due to the erroneous
separator character, and it's dumping your replacement HTML data as a
result.
...
Thanks
Selvi
The same setup with squid-2.5.STABLE13 works properly (the page is
displayed).
What could be the problem?
Thanks for your assistance.
Thanks
Selvi
--
Guy Helmer, Ph.D.
Chief System Architect
Palisade Systems, Inc.
