RE: Squid 3.1.0.14 not sending ICAP Options Request?

I realized after I left yesterday that I had neglected to mention (sorry) that I had also tested with the new configuration commands and received exactly the same behavior. It seemed to make no difference whether I used the 3.0 or 3.1 directives. In my last email I used the old config commands (and attached that file) to demonstrate that the same configuration file produced dramatically different results in 3.1.0.14 (that is, no OPTIONS request) than in 3.0.

To re-iterate, I changed the config commands to the 3.1 version and still received no data from Squid after it makes the connection. Squid immediately closes the connection. I've attached a cache.log with debug information from that execution as well as the conf file using the new directives.

Deb

-----Original Message-----
From: Amos Jeffries [mailto:squid3_at_treenet.co.nz]
Sent: Thursday, October 01, 2009 8:22 PM
To: Schutt, Deborah A
Cc: squid-dev_at_squid-cache.org
Subject: Re: Squid 3.1.0.14 not sending ICAP Options Request?

Schutt, Deborah A wrote:
> I searched the bug list and couldn't find this problem. I don't know
> if it's a 3.1 bug or just something I'm doing wrong.
>
> I've installed release candidate 3.1.0.14 for testing. I've been
> developing an ICAP server and successfully using V3.0.13STABLE for
> testing my server. I wanted to take advantage of the logging in 3.1
> and also start checking out eCAP. However, V3.1 never sends the ICAP
> options request. I've looked at the packets with Wireshark and the
> entire conversation is:
> Squid -> ICAP: SYN
> ICAP->Squid: SYN, ACK
> Squid->ICAP: FIN,ACK
> ICAP->Squid:ACK
> ICAP->Squid: FIN,ACK
> Squid->ICAP:ACK
>
> Squid sends a FIN before my Icap server ever gets an OPTIONS request.
> And the same conversation is repeated as long as squid is up.
>
> I've attached the squid.conf file that I used for testing. The same
> conf file (with the Icap_log directive and the logFormat ICAP
> commented out) works fine for Squid V3.0. V3.0 communicates with the
> ICAP server just fine. It send the OPTIONS requests and then the
> RESPMOD requests I'm expecting.
>
> I've also attached the cache.log with full debugging turned on.
>
> The configure command I used for building this squid is:
> ./configure --prefix=/usr/local/proxy-test/squid31
> --enable-useragent-log --enable-referer-log --enable-ssl
> --enable-large-cache-files --with-pthreads --with-openssl
> --with-large-files --enable-underscores --with-maxfd=16384
> --enable-icap-client --enable-auth="basic negotiate"
> --enable-negotiate-auth-helpers="squid_kerb_auth"
>
> I'm running squid on: Linux sahp3977 2.6.9-89.0.9.EL #1 SMP Wed Aug 19
> 08:08:46 EDT 2009 ia64 ia64 ia64 GNU/Linux And my ICAP server is on:
> Linux test2 2.6.18-128.1.1.el5 #1 SMP Mon Jan
> 26 13:58:24 EST 2009 x86_64 x86_64 x86_64 GNU/Linux
>
> I apologize in advance if I'm doing something stupid, but I'm at a
> loss to figure out what it might be (hence the stupid part :-) If you
> need more information or would like me to test with different options,
> I'd be happy to do so. Thanks for your help (and thanks for Squid
> itself!)
>
> /Deborah/
>

The addition of service chaining in 3.1 changed the ICAP related configuration quite a bit.

icap_class
     Replaced by adaptation_service_set.

icap_access
     Replaced by adaptation_access.

 From what I can see your squid.conf:
  icap_class testresponse testresp
  icap_access testresponse allow all

needs to become:
   adaptation_service_set testresponse testresp
   adaptation_access testresponse allow all

Amos

--
Please be using
   Current Stable Squid 2.7.STABLE7 or 3.0.STABLE19
   Current Beta Squid 3.1.0.14