On 12/05/2016 10:40 AM, Blaxton wrote: > I am using simple java app to test https connectivity through http proxy: > http://alvinalexander.com/blog/post/java/simple-https-example > > If we run below command agains squid running on RedHat: > java -Dhttp.proxyHost=webcache.example.com -Dhttp.proxyPort=808 > JavaHttpsExample > > connection fails , and Squid log file won't even log any thing in log file. If Squid does not listen on port 808 and the IP address(es) that webcache.example.com resolves to, then what you observe is expected. > but if we run: > > java -Dhttps.proxyHost=webcache.example.com -Dhttps.proxyPort=8080 > JavaHttpsExample > > I get response and a line being recorded in log file. If Squid listens on port 8080 and the IP address(es) that webcache.example.com resolves to, then what you observe is expected. > And now running the same app against different squid running on Centos, > I get response from both but nothing being logged with -Dhttp.proxyHost. If you get a response from Squid and then terminate the connection to Squid, then Squid should log something to its access.log file. There are rare exceptions to that rule, but you are very unlikely to hit them with a modern Squid version in such a simple test. > If any one has any tips or any simple app to test different aspect of > https connectivity through squid please let me know. I recommend the following initial tests: 1. ping the Squid listening IP address from the client box 2. telnet to the Squid listening port from the client box 3. use curl or wget on the client box to pass through Squid 4. Now it is time to test with a browser or some obscure Java app! The step #2 (telnet) verifies TCP-level connectivity to the Squid listening port. Typos like 808 instead of 8080 can be caught at this stage. You should be able to connect to Squid, send some garbage input in lieu of an encrypted HTTP request, and receive an error response (or at least a connection termination) from Squid. However, some may consider this telnet test to be too extreme for the 21st century. In all these tests, in complex networking setups, you may have to tell the test app to use the source IP address that the final/intended application will use. It is usually not necessary though. Similarly, some low-level tests cannot work in complex setups (e.g., something between the client and Squid blocks non-SSL traffic), but they usually do. If you cannot get curl or wget to work, then fiddling with some obscure Java app is unlikely to speed up the triage. And if you can get them to work, then you would have a working example to compare the app behavior with. If you continue to have problems, please do not forget to specify what exactly you perceive the problem to be and exactly which logs you have checked. Attaching Squid access.log entries and packet captures (captured on the Squid box) often helps as well. HTH, Alex. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
