[squid-users] Using Squid as forward http proxy failing to complete request?

[asad]

Amos thanks. I was sick over the weekend thus the late reply

Sorry by mistake I left out the mailing-list email on previously mail.
I would look into the donation link and see how I can tribute :).

Bug:) that was unexpected. I thought it was routine debugging work.

Here is output of squid -v


"
Squid Cache: Version 3.5.7-20150808-r13884
Service Name: squid
configure options:  '--bindir=/bin/squid' '--sbindir=/usr/sbin/squid'
'--sysconfdir=/etc/squid' '--datadir=/usr/share/squid'
'--libexecdir=/usr/lib/squid' '--disable-strict-error-checking'
'--with-logdir=/var/log/squid' '--with-swapdir=/var/cache/squid'
'--with-pidfile=/var/run/squid.pid' '--enable-ssl'
'--enable-delay-pools' '--enable-ssl-crtd' '--enable-icap-client'
'--enable-esi' '--disable-eui' '--localstatedir=/var/run/squid'
'--sharedstatedir=/var/run/squid' '--datarootdir=/usr/share/squid'
'--enable-disk-io=AIO,Blocking,DiskThreads,IpcIo,Mmapped'
'--enable-auth-basic=DB,LDAP,NCSA,POP3,RADIUS,SASL,SMB,fake,getpwnam'
'--enable-auth-ntlm=fake' '--enable-auth-negotiate=kerberos,wrapper'
'--enable-external-acl-helpers=LDAP_group,SQL_session,eDirectory_userip,file_userip,kerberos_ldap_group,session,time_quota,unix_group,wbinfo_group'
'--with-openssl' '--with-filedescriptors=65536'
'--enable-removal-policies=lru,heap'
"

The last output of http-headers was taken from cache.log itself.

regards
Aasad


On 8/28/15, Amos Jeffries <squid3 at treenet.co.nz> wrote:
> On 28/08/2015 10:50 p.m., asad wrote:
>> Sorry I complete missed this reply from you.
>>
>
> We'd probably get back to cc'ig the list if you dont mind.
> I try to restrict private help to my paying clients.
>
> Though if you would care to donate what you think a fair value I happy
> to continue in private; <http://treenet.co.nz/projects/squid/>
>
>
>> I enabled debugging , and here is the results from cache.log file.
>>
>>
>> Here is one for https://www.google.com
>>
>> "2015/08/28 15:45:00.749 kid1| client_side.cc(2337) parseHttpRequest:
>> HTTP Client local=127.0.0.1:3128 remote=127.0.0.1:64062 FD 16 flags=1
>> 2015/08/28 15:45:00.749 kid1| client_side.cc(2338) parseHttpRequest:
>> HTTP Client REQUEST:
>> ---------
>> CONNECT www.google.com.pk:443 HTTP/1.1
>> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0)
>> Gecko/20100101 Firefox/40.0
>> Proxy-Connection: keep-alive
>> Connection: keep-alive
>> Host: www.google.com.pk:443
>>
>>
>> ----------
>> 2015/08/28 15:45:00.751 kid1| tunnel.cc(1103)
>> tunnelRelayConnectRequest: Tunnel Server REQUEST:
>> local=10.10.131.13:64063 remote=10.10.32.4:8080 FD 19 flags=1:
>> ----------
>>  tunnelRelayConnectRequest[267]"
>
> Drat. Well you have found a bug in the debugging code. :-(
>
> That should be listing what was attempting to leave. But
> tunnelRelayConnectRequest is just where the 267 byte string was stored.
>
> What is your squid -v output? I'm probably going to have to give you a
> patch for this.
>
>>
>>
>> Interestingly, in both the case there is no response the request never
>> left my machine running squid proxy. I hope you can shed some light on
>> this.
>
> Yes that is interesting. I'm seeing something similar here now with
> Squid-4 trying to resolve the above bug. Not sure if its a stupid
> mistake in my rough test setup or something else.
>
> Did you get that from packet traces or something independent of Squid?
>
>
> Cheers
> Amos
>