<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Wow thank you Amos for that information.<div class=""><br class=""></div><div class="">I must read, research, digest, read and then attempt to figure out what the problem is. :-)</div><div class=""><br class=""></div><div class="">Will be in touch if there are any further issues. Thank you.<br class=""><div apple-content-edited="true" class="">
<div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br style="orphans: 2; widows: 2;" class=""><span style="orphans: 2; widows: 2;" class="">~ Laz Peterson</span><br style="orphans: 2; widows: 2;" class=""><span style="orphans: 2; widows: 2;" class="">Paravis, LLC</span><br style="orphans: 2; widows: 2;" class=""></div><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><span style="orphans: 2; widows: 2;" class=""><br class=""></span></div></div><div><blockquote type="cite" class=""><div class="">On Jul 19, 2015, at 9:03 AM, Amos Jeffries <<a href="mailto:squid3@treenet.co.nz" class="">squid3@treenet.co.nz</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">On 18/07/2015 1:42 a.m., Laz C. Peterson wrote:<br class=""><blockquote type="cite" class="">Hello all,<br class=""><br class="">Very weird issue here. This happens to only select Citrix support articles. (For example, <a href="http://support.citrix.com/article/CTX122972" class="">http://support.citrix.com/article/CTX122972</a> <<a href="http://support.citrix.com/article/CTX122972" class="">http://support.citrix.com/article/CTX122972</a>> when searching Google for “citrix netscaler expired password” which is the top link in my results, or also searching for the same article directly on Citrix support site.)<br class=""><br class="">This is a new install of Squid 3 on Ubuntu 14.04.2 (from Ubuntu repository). When clicking the Google link, I get “too many redirects” error, saying that possibly the page refers to another page that is then redirected back to the original page.<br class=""><br class="">I tried debugging but did not find much useful information. Has anyone else seen behavior like this?<br class=""><br class=""></blockquote><br class="">The problem is the client fething URL X, gets a 30x redirect message<br class="">instructing it to contacts URL X instead (X being same URL X it *was*<br class="">fetching).<br class=""><br class="">Usually that is a miconfiguration on the origin server itself. Fixable<br class="">only by the origin site authors. But there are also a few ways Squid can<br class="">play a part:<br class=""><br class="">1) The 30x response pointing to itself (wrongly) really was generated by<br class="">the server and also explicitly stated that it should be cached [or you<br class="">configured Squid to force-cache].<br class=""><br class="">Squid obeyed, and now you keep getting these loops. That will continue<br class="">until the cached content expires or is purged.<br class=""><br class=""><br class="">2) You are using Store-ID/Store-URL feature of Squid and did not check<br class="">that the URLs being merged were identical output. One of them produces a<br class="">302 redirect to X, which got cached. So now fetches for any URL in the<br class="">merged set (including the X itself) gets the cached 302 redirect back to X.<br class="">Again, that will continue until the cached content expires or is purged.<br class=""><br class=""><br class="">3) You are using a URL redirector that is generating the 302 response<br class="">loop. Usually redirectors with badly written (overly inclusive) regex<br class="">patterns causing similar behaviour to (2).<br class=""><br class=""><br class="">4) You are using a URL re-writer that is taking client request URL Y and<br class="">(wrongly) re-writing it to X. Squid fetches X from the backend server,<br class="">which replies with a redirect to Y (because Y != X). ... and loop.<br class=""><br class=""><br class="">5) You could be directing traffic using a cache_peer on port 80<br class="">regardless of http:// or https:// scheme received from the clients. If<br class="">the receiving peer/server emits a 302 for all traffic arriving on its<br class="">port 80 to a https:// URL this sort of loop happens. Its a slightly more<br class="">complicated form of (4), using a cache_peer equivalent of URL re-writer.<br class=""> The best fix for that is at the server. RFC 7230 section 5.5 has an<br class="">algorithm for what compliant servers should be doing. Squids job is to<br class="">relay the request and URL unchanged.<br class=""><br class="">Amos<br class=""><br class="">_______________________________________________<br class="">squid-users mailing list<br class=""><a href="mailto:squid-users@lists.squid-cache.org" class="">squid-users@lists.squid-cache.org</a><br class="">http://lists.squid-cache.org/listinfo/squid-users<br class=""></div></blockquote></div><br class=""></div></body></html>