Thanks for Henrik and Christos' suggestions. It is great that Henrik's first suggestion works to me. I reported the problem to the GreasySpoon author few days ago, but it takes time to find the root course. Basically, I replace icap_access class_1 allow all icap_access class_2 allow all with icap_access class_1 deny POST icap_access class_2 deny POST It seems like there is a communication problem between Squid and GreasySpoon on POST method. I will base on Henrik's second suggestion to log for GreasySpoon author to check. (I assume Squid doesn't have this problem because Christos tried 1-2 ICAP servers and they all worked well.) Thanks a lot for your help! - Jones On Tue, Jul 15, 2008 at 2:53 PM, Henrik Nordstrom <henrik@xxxxxxxxxxxxxxxxxxx> wrote: > On mån, 2008-07-14 at 15:21 -0400, Jones wrote: >> Thanks to developers' hard work to let us enjoy the Squid. Currently, >> I am using Squid 3.0 Stable 7 + ICAP client and GreasySpoon (ICAP >> server) to customize the page. It works pretty well in Debian. >> >> However, when I browse the page, which has a form with "POST" >> method,the page will load repeatedly without finishing, such as >> http://www.redbox.com/Titles/Availabletitles.aspx. (The "POST" method >> can work well if I disable ICAP client inside Squid.) I check the >> Squid log and GreasySpoon access.log and found following messages: >> >> 1. Squid access.log: >> TCP_MISS/200 751 GET http://XXXXXX/main.php - DIRECT/XXX.XXX.XXX.XXX text/html >> TCP_MISS/200 541 GET http://XXXXXX/script.php - DIRECT/XXX.XXX.XXX.XXX >> text/javascript >> >> 2. GreasySpoon access.log: >> [REQMOD ] [greasyspoon] ICAP/200 HTTP/POST http://XXXXXXX/confirm.php > > Does it help if you deny POST from being sent ot ICAP? > > acl POST method post > icap_access your_icap_class deny POST > >> However, I don't see any POST http in squid log, which might be the >> reason to cause the page to load repeatedly. (But I can see TCP >> package [TCP segment of a reassembled PDU], which contains Post method >> message.) > > Sounds very strange. > > If you can I would suggest filing a bug and include the following data: > > 1. Restart Squid with no other clients accessing it. > > 2. Enable full debugging by running "squid -k debug" once (toggles > debugging on/off) > > 3. Save a network trace of the HTTP and ICAP traffic > tcpdump -w post_request.pcap -i any -p -s 0 port yourproxyport or port 80 or port 1344 > > (if the POST is not directed to port 80 or your icap server is not > using 1344 then adjust as appropriate...) > > 4. Make the failing POST request. > > 5. Stop tcpdump > > 6. Stop Squid debugging by running "squid -k debug" again. > > And then file a bug report and attach your cache.log and > post_request.pcap files. > > > Note: Avoid using any sensitive details such as restricted logins or > personal data in this test. The bug reports are public. > >> Does anyone encounter similar problem with ICAP client? > > Haven't heard of this kind of problem before. > >> I appreciate >> anyone who can give me some suggestions or point me to past related >> mail to know how to fix it. Sorry if this is a repeated question. >> Thanks for any suggestion. > > I would probably begin by looking at the ICAP traffic to verify that the > response from the ICAP server makes sense.. maybe the ICAP server > rewrites the request into a GET in the REQMOD response? > > But it coule also be a Squid bug.. > > Regards > Henrik > >
