Amos Jeffries wrote > 2) explicit hostname "serverb.domain:9443". I find it highly unlikely > that you will be finding server A being requested for URLs at that > hostname.
We now have the public URL for app.domain set to servera.domain. Amos Jeffries wrote > 1) https:// on the URLs. Squid is not suposed to be sending these over > un-encrypted peer connections. I dont recall any explicit prevention of > that, but there might be. A little progress finally, we have two types of clients for our app server, one is web browser, and the other is eclipse, for the same request, server B will try to query server A ONLY if the request is sent by web browser, i tried to look into the log file in server A, no difference between URLs for the requests sent by these two types of clients, strange? # record for request sent by web browser in server B 1406539824.298 3 172.17.210.5 TCP_MISS/200 3736 GET https://servera.domain:9443/ccm/service/com.ibm.team.scm.common.IVersionedContentService/content/com.ibm.team.filesystem/FileItem/_J-m1gK4-EeOvOJ84krOqLg/_fOPWkv3TEeOaa7Y2RPnTQg/FHFMF8a7A01tlvpKekGYG9gxlVc3bigGpRMSA11YKZ4 - SIBLING_HIT/172.17.192.33 application/octet-stream # record for request sent by eclipse in server B 1406540067.167 409 172.17.210.5 TCP_MISS/200 3670 GET https://servera.domain:9443/ccm/service/com.ibm.team.scm.common.IVersionedContentService/content/com.ibm.team.filesystem/FileItem/_J-m1gK4-EeOvOJ84krOqLg/_fOPWkv3TEeOaa7Y2RPnTQg/FHFMF8a7A01tlvpKekGYG9gxlVc3bigGpRMSA11YKZ4 - FIRSTUP_PARENT/172.17.96.148 application/octet-stream -- View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/Sibling-cache-peer-for-a-HTTPS-reverse-proxy-tp4667011p4667076.html Sent from the Squid - Users mailing list archive at Nabble.com.
