Re: [squid-users] Need help with POST problem in Squid 3.0 + ICAP client

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_at_henriknordstrom.net> 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
>
>
Received on Tue Jul 15 2008 - 19:40:12 MDT