I try to use this function on SQLA 10.0.1.3976 as a test.
But always get a connection timeout.
The squid access log shows the following lines when I run the function on my sql server
When is start the request with Internet explorer the same URL
For me it looks like SQLA uses a different request type.
Thanks for your time.
asked 09 Feb '10, 12:52
This issue appears to be a Squid configuration problem and not a issue with SQL Anywhere.
First some background: When you use the 'proxy' clause in your SQL Anywhere http client procedure declaration, SA does change it behaviour slightly: Instead of making a connection to the specified URL, it connects to the specified proxy address & port and sends the adjusted http[s] request to the proxy server (i.e. the URL sent in the request contains the full //host:port/url instead of just /url).
Here's my guess on what has happened:
Initially your Squid configuration was set to only allow port 443 on outgoing connections (look for a line that looks like
or perhaps your config says
Either way, your squid proxy server was not allowing outgoing port 80 connections. When you added 80 to the list of "ssl_ports", the http_access rules then allowed the connection to occur. (Note that "ssl_ports" is simply a name given to an "access rule".)
Take a look at your squid.conf file, and specifically the http_access rules, to figure out and understand your current configuration. Depending on what you really want to do (in terms of what you want your proxy server to allow) you can then decide upon a solution that best suits your needs.
I found out that CONNECT is normaly used for SSL Connections. My SSL_port directive allows Port 443 only.
My Workaround is to add Port 80 to the Valid SSL Ports in squid.conf.
Is there a other solution ? Is SQLA standard conform in regards to web client connections ?
answered 09 Feb '10, 12:57