Thank you so much Amos! You figured it out!
I was able to telnet to those ports from my localhost, but not from the
server where squid is installed. I'm working to get those ports opened now.
Thanks again!
On Mon, Nov 30, 2015 at 7:08 PM, Amos Jeffries wrote:
> On
Well I am packing for CentOS and not RH which might have some differences.
I will try to test my RPM on a clean CentOS machine and see if there is
any regression in the build.
Eliezer
On 30/11/2015 18:17, bspedden wrote:
I'm on RedHat 6.7
lsb_release -i -r
Distributor ID:
Thanks Eliezer. I'll grab the source for 3.5.12 and compile - I'll you know
how it goes.
On Mon, Nov 30, 2015 at 9:43 AM, Eliezer Croitoru
wrote:
> Well I am packing for CentOS and not RH which might have some differences.
> I will try to test my RPM on a clean CentOS
On 30/11/2015 18:55, Bart Spedden wrote:
Thanks Eliezer. I'll grab the source for 3.5.12 and compile - I'll you know
how it goes.
Hey I have checked it against CentOS and it seems to work file.
I assume that there is a difference between CentOS and RH.
I will be happy to release a package
Well, interestingly, it seems like the install from the rpm worked.
squid -v
Squid Cache: Version 3.5.11
However, I still see the same error. I also tried the following
configuration thinking that it would allow ssl on any port and I still the
same error:
#http_access deny CONNECT !SSL_ports
It seems like the issue is not in the basic access control but rather in
the TCP level.
a 503 means some kind of network errors in most cases.
Have you tried contacting the site\ip using netcat or openssl -sa ?
Eliezer
On 30/11/2015 19:40, Bart Spedden wrote:
Well, interestingly, it seems
I can successfully connect as long as I don't use squid for either 1 way or
2 way TLS connections. I've also successfully connect via curl. So, I feel
like the site's certs are working well. I could be totally off base here
but my interpretation of the the 503 (service unavailable) is that squid
On Monday 30 November 2015 at 18:53:54, Bart Spedden wrote:
> I can successfully connect as long as I don't use squid for either 1 way or
> 2 way TLS connections. I've also successfully connect via curl. So, I feel
> like the site's certs are working well. I could be totally off base here
> but
On 1/12/2015 1:01 p.m., Bart Spedden wrote:
> In the cache.log I have found the following:
>
> CONNECT tv1var.merchantlink-lab.com:8184 HTTP/1.1^M
>
> User-Agent: Java/1.8.0_05^M
>
> Host: tv1var.merchantlink-lab.com:8184^M
>
> Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2^M
>
Good idea Anthony.
Here's what I found.
On the squid server when I use the following command to monitor a call to
https://www.google.com
tcpdump -i eth0 -vv 'port 443'
I get the following:
17:32:56.373772 IP (tos 0x0, ttl 64, id 33502, offset 0, flags [DF], proto
TCP (6), length 60)
In the cache.log I have found the following:
CONNECT tv1var.merchantlink-lab.com:8184 HTTP/1.1^M
User-Agent: Java/1.8.0_05^M
Host: tv1var.merchantlink-lab.com:8184^M
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2^M
Proxy-Connection: keep-alive^M
^M
--
2015/11/30
On 25/11/2015 11:41 a.m., Bart Spedden wrote:
> Hello,
>
> I have a java application that is successfully making REST calls to a 3rd
> party vendor that requires 2 way SSL on port 8184 for some calls and 1 way
> SSL on port 8185 for other calls. However, when I start proxying the calls
> with
Hey Bart,
What OS are you using? I have just pushed the latest(3.5.11) CentOS
RPMs, details at: http://wiki.squid-cache.org/KnowledgeBase/CentOS .
Eliezer
On 25/11/2015 02:11, Amos Jeffries wrote:
That said, there are a few major bugs in CONNECT handling that have been
uncovered and fixed
Hello,
I have a java application that is successfully making REST calls to a 3rd
party vendor that requires 2 way SSL on port 8184 for some calls and 1 way
SSL on port 8185 for other calls. However, when I start proxying the calls
with squid all 1 and 2 way SSL calls fail.
I added ports 8184 and
14 matches
Mail list logo