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
