Re: [squid-users] Re: Sibling cache peer for a HTTPS reverse proxy
On 28/07/2014 9:37 p.m., Makson wrote: 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.167409 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 Excellent. Would you be able to show the HTTP request coming from each of those celints, and the HTTP reply coming from the origin parent server? debug_options 11,2 will log the necessary details in the current squid releases. Older Squid require tcpdump -s0 to capture them all. Amos
Re: [squid-users] Re: Sibling cache peer for a HTTPS reverse proxy
I was looking for Vary headers from the origin server. But none visible. Instead I see 1) broken cacheability headers. The Expires: header says (Date: + 360 days), and s-maxage says 360days BUT ... Last-Modified says 1970. So Last-Modified + s-maxage is already expired. NP: this is not breaking Squid which still (incorrectly) uses Expires header in preference to s-maxage. But when we fix that bug this server will start to MISS constantly. 2) Authorization: header from eclipse. Server-authenticated requests can receive cached content but require revalidation to the server to confirm that the content is legit for this user. The server is responding with a whole new response object (200) where I would expect a 304. Does the matching HTTP Server REQUEST to the parent peer for the eclipse transaction contain an If-Modified-Since and/or If-Match header? Amos
Re: [squid-users] Re: Sibling cache peer for a HTTPS reverse proxy
On 29/07/2014 3:39 a.m., Makson wrote: Amos Jeffries wrote 1) broken cacheability headers. The Expires: header says (Date: + 360 days), and s-maxage says 360days BUT ... Last-Modified says 1970. So Last-Modified + s-maxage is already expired. NP: this is not breaking Squid which still (incorrectly) uses Expires header in preference to s-maxage. But when we fix that bug this server will start to MISS constantly. So this is caused by the application? It is made by IBM, if you fix this bug, i guess we need to keep using the older version of Squid. Amos Jeffries wrote Does the matching HTTP Server REQUEST to the parent peer for the eclipse transaction contain an If-Modified-Since and/or If-Match header? Sorry, i didn't get that, would you please explain me in more detail? There is a HTTP request to the parent server leading to that reply you posted the headers for. What is the request headers? Amos
Re: [squid-users] Re: Sibling cache peer for a HTTPS reverse proxy
On 27/07/2014 1:34 a.m., Makson wrote: Amos Jeffries wrote Showing that server B is in fact qeuerying server A for the objects. But it would seem that server A did not have them cached. It may be that these responses use Vary: header. ICP does not handle that type of response properly. You may get better behaviour using HTCP instead of ICP between the siblings. I also note that you have 40GB of RAM allocated to each of these Squid instances. Do you actually have over 100GB of RAM on those machines (*excluding* swap space)? Amos Hi Amos, Thanks for your reply, i am now using HTCP, still don't get it work :-( , Ah. Been scratching my head over this for a while. The log records you mentioned shoed two things hich might be interfering. 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. 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. All publicly visible URLs from app.domain going through these proxies should be using the public[1] domain name for app.domain's service, not the proxies unique hostname:port's. That includes your testing requests. [1] public in the context that clients are told it, not necessarily Internet-public. Amos
Re: [squid-users] Re: Sibling cache peer for a HTTPS reverse proxy
On 26/07/2014 11:44 a.m., Makson wrote: Thanks for your reminder, i think the HTML RAW tag caused the problem, send the log again. Some records found in access.log in server b, 1406185920.441 1282 172.17.210.5 TCP_MISS/200 814 GET https://serverb.domain:9443/ccm/service/com.ibm.team.scm.common.IVersionedContentService/content/com.ibm.team.filesystem/FileItem/_houAAK2yEeOvOJ84krOqLg/_EPGIsq20EeOEJLtkkn17bg/h2LjUv8WJVDwJ3rcbA6_u3fNuJylQ0sQlSZdRL_IMkA - FIRSTUP_PARENT/172.17.96.148 application/octet-stream 1406185921.151 46349 172.17.210.5 TCP_MISS/200 219202 GET https://serverb.domain:9443/ccm/service/com.ibm.team.scm.common.IVersionedContentService/content/com.ibm.team.filesystem/FileItem/_hpCwIK2yEeOvOJ84krOqLg/_EN-HVK20EeOEJLtkkn17bg/rnslrsXloPXpudCIXRFjShexoc97mr7-2RxWPs7pVnI - FIRSTUP_PARENT/172.17.96.148 application/octet-stream All records found in access.log in server a, 1406185543.094 0 172.17.192.145 UDP_MISS/000 124 ICP_QUERY https://serverb.domain:9443/ccm/authenticated/identity?redirectPath=%2Fccm%2Fjauth-issue-token - HIER_NONE/- - 1406185544.871 0 172.17.192.145 UDP_MISS/000 79 ICP_QUERY https://serverb.domain:9443/ccm/auth/authrequired - HIER_NONE/- - 1406185565.202 0 172.17.192.145 UDP_MISS/000 124 ICP_QUERY https://serverb.domain:9443/ccm/authenticated/identity?redirectPath=%2Fccm%2Fjauth-issue-token - HIER_NONE/- - 1406185566.732 0 172.17.192.145 UDP_MISS/000 79 ICP_QUERY https://serverb.domain:9443/ccm/auth/authrequired - HIER_NONE/- - 1406185615.090 0 172.17.192.145 UDP_MISS/000 124 ICP_QUERY https://serverb.domain:9443/ccm/authenticated/identity?redirectPath=%2Fccm%2Fjauth-issue-token - HIER_NONE/- - Showing that server B is in fact qeuerying server A for the objects. But it would seem that server A did not have them cached. It may be that these responses use Vary: header. ICP does not handle that type of response properly. You may get better behaviour using HTCP instead of ICP between the siblings. I also note that you have 40GB of RAM allocated to each of these Squid instances. Do you actually have over 100GB of RAM on those machines (*excluding* swap space)? Amos
Re: [squid-users] Re: Sibling cache peer for a HTTPS reverse proxy
On 07/24/2014 02:57 AM, Makson wrote: And here are some records found in access.log in server b, here are ALL records found in access.log in server a, -- Sent from the Squid - Users mailing list archive at Nabble.com. Just FYI: The above is how Babble sends your email to the mailing list. Notice that all the log lines are gone. HTH, Alex.
