Re: [RFC] CONNECT and use_ssl cache_peer

2012-09-08 Thread Henrik Nordström
fre 2012-09-07 klockan 21:54 -0600 skrev Alex Rousskov: However, when the proxy receives a CONNECT request, it diverts the request to tunnel.cc. Tunnel.cc is aware of peer selection logic but lacks the code that establishes an SSL connection to SSL peers. Yes, long time bug that no one has

Re: [RFC] CONNECT and use_ssl cache_peer

2012-09-08 Thread Alex Rousskov
On 09/07/2012 10:38 PM, Amos Jeffries wrote: On 8/09/2012 3:54 p.m., Alex Rousskov wrote: Hello, I came upon a Squid proxy configured with cache_peer ssl (i.e., peer-use_ssl is true). The proxy forwards GETs to the peer using an SSL connection because forward.cc code knows that SSL

Re: Store_url_rewrite for squid 3+

2012-09-08 Thread Alex Rousskov
On 09/07/2012 09:13 PM, Amos Jeffries wrote: Also, any revalidation requests done later must be done on the original request URL. Not the stored URL nor the potentially different current client request URL. This sounds like a very important point that could justify storing the original

Re: ICAP connections under heavy loads

2012-09-08 Thread Alex Rousskov
On 09/07/2012 09:51 PM, Amos Jeffries wrote: On 8/09/2012 3:17 a.m., Alex Rousskov wrote: On 09/07/2012 08:33 AM, Alexander Komyagin wrote: However, as I stated earlier, the comm.cc problem (actually semantics problem) persists. I think it should be documented that second and subsequent calls

Re: Store_url_rewrite 2.7 vs\to 3.head basic review

2012-09-08 Thread Alex Rousskov
On 09/08/2012 06:24 AM, Eliezer Croitoru wrote: (I will respond to the other emails also) A moment before I will get back to the 3.head I want to review what was done on 2.7 vs 3.head before even touching the code. summary: squid 2.7 store_url_rewrite makes use of

Re: Store_url_rewrite 2.7 vs\to 3.head basic review

2012-09-08 Thread Eliezer Croitoru
On 09/08/2012 08:18 PM, Alex Rousskov wrote: On 09/08/2012 06:24 AM, Eliezer Croitoru wrote: (I will respond to the other emails also) A moment before I will get back to the 3.head I want to review what was done on 2.7 vs 3.head before even touching the code. summary: squid 2.7

Build failed in Jenkins: 3.2-matrix » obsd-51-x86 #262

2012-09-08 Thread noc
See http://build.squid-cache.org/job/3.2-matrix/./label=obsd-51-x86/262/ -- Started by upstream project 3.2-matrix build number 262 Building remotely on obsd-51-x86 in workspace http://build.squid-cache.org/job/3.2-matrix/./label=obsd-51-x86/ws/

Build failed in Jenkins: 3.2-matrix » east #262

2012-09-08 Thread noc
See http://build.squid-cache.org/job/3.2-matrix/./label=east/262/ -- Started by upstream project 3.2-matrix build number 262 Building remotely on east in workspace http://build.squid-cache.org/job/3.2-matrix/./label=east/ws/ Cleaning workspace... $ bzr

Build failed in Jenkins: 3.2-matrix » opensuse-x64 #262

2012-09-08 Thread noc
See http://build.squid-cache.org/job/3.2-matrix/./label=opensuse-x64/262/changes Changes: [Amos Jeffries] Bug 3616: Retrieve client connection for ACL checks from the related HttpRequest object This patch enable SSL client certificate ACL checks (user_cert and ca_cert) in all cases the client