RE: [squid-users] ssl-bump pause for 2 minutes for certain sites

Hi Amos,

The pause happens when ICAP sends about 90% of the payload. The Content-Length header shown the exact size as 106900. I believe by the time squid starts to send the RESPMOD payload, all the DNS should already finished.

If you look at the tcpdump on port 443, it pauses for 2 minutes and then RST by the web server. There is no additional data coming in after the pause from the webserver on port 443. So squid must already have the payload in full, but some how didn't do anything until kicked by the RST from the web server. After squid resume sending the ICAP payload, it actually sent in several 600 to 1400 sized packets. So it does not look like that the web server was holding back the payload.

Regards,
Ming

-----Original Message-----
From: Amos Jeffries [mailto:squid3_at_treenet.co.nz]
Sent: December-16-10 8:49 PM
To: squid-users_at_squid-cache.org
Subject: Re: [squid-users] ssl-bump pause for 2 minutes for certain sites

On 17/12/10 08:45, Ming Fu wrote:
> Hi,
>
> When using squid 3.1.9 and ssl-bump, access to
> https://www.e-secure-it.com/info.html will cause squid RESPMOD to
> pause for about 2 minutes when sending the body playload to the ICAP
> server. The payload will eventually arrive. Just can't explain what
> happens during the 2 minute.
>
> Tcpdump on port 443 show that there is a pause during the end of SSL
> transaction with the e-secure. The time of the port 443 pause
> correlates to the pause of ICAP body upload. But there is no such
> pause when browser is direct connected to the e-secure site without
> squid in the middle.
>

You seem to have answered your own question. Sending stuff to that ICAP
server is very slow.

Other things to consder:
  * Did the packets actually stop completely at that point? or did
something else happen?
  * look at DNS etc as well. Squid may be waiting on the ICAP server
name to resolve.
  * take a full packet traces (tcpdump -s 0 ...) and see what is
actually being transfered to/from ICAP. It could be non-HTTP, broken
syntax, or any kind of secondary encoding inside a HTTPS security channel.

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.9
   Beta testers wanted for 3.2.0.3