What will be the implications of reversing the change? On Mon, Apr 16, 2012 at 12:30 PM, Amos Jeffries <squid3@xxxxxxxxxxxxx> wrote: > On 16/04/2012 6:46 p.m., Ahmed Talha Khan wrote: >> >> These options of vport and protocol are valid in the accelerator >> mode(reverse-mode) whereas i am using the forward mode. > > > Aw. heck. I think we have bite-back from > http://bugs.squid-cache.org/show_bug.cgi?id=2976. > The temporary workaround applied was to hard-code http:// scheme on > intercepted requests. At the time it made sense, but now not so much. > > You can reverse the patch http://bugs.squid-cache.org/attachment.cgi?id=2375 > for now to get it going (mostly). > > The port changes needed for full fix to that bug are nearly ready for audit > now. I will push that a little harder to get it finished. > > Amos > > > >> On Sat, Apr 14, 2012 at 10:30 AM, Amos Jeffries wrote: >>> >>> On 13/04/2012 10:50 p.m., Ahmed Talha Khan wrote: >>>> >>>> Hey Amos, >>>> I made headway with the the problem :).. I think the looping is >>>> happening because squid is proxying the https port traffic onto http >>>> port on the way out. >>>> >>>> clientt----https=443---------->squid---------http=80----->origin server >>>> >>>> I can see the external connection being setup-ed on port 80 whereas it >>>> should have been on port 443. That is why the server keeps sending me >>>> back the same url to re-direct to.. This is my theory...What do you >>>> think about it? Also how i can make squid to output the original port >>>> 443 traffic on port 443 when connecting to the external servers...i >>>> could see something you mentioned to another guy here >>>> >>>> >>>> >>>> http://squid-web-proxy-cache.1019090.n4.nabble.com/squid-3-1-endless-loop-IIS-webserver-td4465329.html >>>> >>>> >>>> This example was a reverse proxy example and might not work for >>>> me...Any suggestions? I think we are about to crack it !!:) >>> >>> >>> The problem there seemed to be caused by the cache_peer being a >>> plain-HTTP >>> link. >>> >>> Your seems to be more a matter of the URL interpretation not being quite >>> right. "vport=443" and/or "protocol=https" might work. >>> >>> Amos >> >> >> > -- Regards, -Ahmed Talha Khan
