[squid-users] Infinite loop when sending request to HTTPS reverse proxy

From: <michael173_at_gmx.net>
Date: Thu, 1 Dec 2011 00:02:09 +0100

We would like to set up squid as a reverse accelerator proxy, to talk HTTPS on both ends. The client shall contact the proxy via HTTPS, and the proxy shall talk to the application server via HTTPS.

We got it all set up, but for some reason, our squid goes into an infinite loop as soon the client browser sends it first request after accepting the Proxy's SSL-certificate. The client session just hangs. The cache.log fills with the repeating sequence pasted below. Maybe the solution is obvious, but it seems too obvious for us. So - any hint or help would be greatly appreciated. What can we do to further dig into the root cause? Should we just compile squid from scratch?

Out OS is RHEL6, Squid is 3.1.10. We installed the regular squid.x86_64 packet, and used ldd to make sure it's got the SSL libs linked in.

Our squid.conf is this:
----------------------------------------------
cache_replacement_policy heap GDSF
memory_replacement_policy heap GDSF
cache_dir aufs /var/cache/squid 4096 256 256
cache_mem 2048 MB
cache_store_log none
cache_peer (our-app-server) parent 9443 0 no-query originserver name=httpsAccel login=PROXYPASS ssl sslflags=DONT_VERIFY_PEER
cache_peer_access httpsAccel allow all
coredump_dir /var/log/squid
http_access allow all
#http_port <proxy.port> accel vhost
https_port 9445 cert=/etc/squid/server.pem key=/etc/squid/privkey.pem accel vhost
refresh_pattern . 0 20% 4320
cachemgr_passwd disable all
maximum_object_size 1024 MB
maximum_object_size_in_memory 16 MB
buffered_logs on
visible_hostname (our-proxy-hostname)
----------------------------------------------

The cache.log is repeating itself with this sequence. I am asking myself, what the heck is it doing here?
----------------------------------------------
2011/11/30 15:40:00.000| entering storeClientCopyEvent(0x7f6aa5b2ede8*?)
2011/11/30 15:40:00.000| AsyncCall.cc(32) make: make call storeClientCopyEvent [call663369801]
2011/11/30 15:40:00.000| storeClientCopyEvent: Running
2011/11/30 15:40:00.000| storeClientCopy2: 34A108D8256927160090E868D0CADAED
2011/11/30 15:40:00.000| store_client::doCopy: co: 134, hi: 134
2011/11/30 15:40:00.000| store_client.cc(349) doCopy: There is no more to send!
2011/11/30 15:40:00.000| peerDigestHandleReply: peer (our-app-server), offset: 134 size: 7.
2011/11/30 15:40:00.000| peerDigestSwapInCBlock: peer (our-app-server), offset: 134 size: 7.
2011/11/30 15:40:00.000| store_client::copy: 34A108D8256927160090E868D0CADAED, from 134, for length 4089, cb 1, cbdata 0x7f6aa5b2da28
2011/11/30 15:40:00.000| storeClientCopy2: Queueing storeClientCopyEvent()
2011/11/30 15:40:00.000| event.cc(343) schedule: schedule: Adding 'storeClientCopyEvent', in 0.00 seconds
2011/11/30 15:40:00.000| leaving storeClientCopyEvent(0x7f6aa5b2ede8*?)
2011/11/30 15:40:00.000| event.cc(251) checkEvents: checkEvents
2011/11/30 15:40:00.000| The AsyncCall storeClientCopyEvent constructed, this=0x7f6aa5b2ff50 [call663369802]
2011/11/30 15:40:00.000| event.cc(260) will call storeClientCopyEvent(0x7f6aa5b2ede8*?) [call663369802]
----------------------------------------------

Thanks for your help!
Kind regards,
Michael
Received on Wed Nov 30 2011 - 23:02:18 MST

This archive was generated by hypermail 2.2.0 : Thu Dec 01 2011 - 12:00:03 MST