Re: [squid-users] Using squid as transparent proxy causes problem with pages on https

What will be the implications of reversing the change?

On Mon, Apr 16, 2012 at 12:30 PM, Amos Jeffries <squid3_at_treenet.co.nz> 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