[squid-users] HTTPS through http proxy

[Alex Rousskov]

On 12/05/2016 11:34 PM, Blaxton wrote:

> most of our applications are written in Java and I have to test it with
> this small java application to understand our users.

That is step #4. You are missing steps #1-3.

Imagine you are a semi-unconscious emergency room patient complaining of
severe headaches. Do you want the doctors to immediately open up your
skull to see if there is anything wrong with your brain (because your
head is what you are complaining about)? That would be step #4.

Or do you want them to start with taking your temperature and blood
pressure? That would be steps #1-3.


HTH,

Alex.


> ------------------------------------------------------------------------
> *From:* Alex Rousskov <rousskov at measurement-factory.com>
> *To:* "squid-users at lists.squid-cache.org"
> <squid-users at lists.squid-cache.org>
> *Cc:* Blaxton <blaxxton at yahoo.com>
> *Sent:* Monday, December 5, 2016 2:11 PM
> *Subject:* Re: [squid-users] HTTPS through http proxy
> 
> 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.