Re: [squid-users] any work arounds for bug 2176

On Thu, Dec 17, 2009 at 10:10:12PM +1300, Amos Jeffries wrote:
>
> Which is off. Now I'm confused.
>

I know the feeling well :)

> >
> >I am a C coder and may have some time to do some debugging on this
> >between christmas and new year so, Amos, if you have any thoughts or
> >hints as to where to go looking I can certainly have a stab at it.
> >
>
> Thank you. Any help at all would be great.
>
> I *think* the relevant code is off src/client_side_reply.cc, but what to
> look for is where I'm currently stuck. The keep_alive values resolved
> things for you Brett but not Bill.
>

src/client_side.c? I think you are referring to a squid 3 file there
at a guess since it is c++

>
> The variable nature of the threshold looks like some timing between
> actions triggering the bug vs the rate at which Squid is sucking the
> request in.
>

I have done some traces and it looks like the entire file is not being
sent to the remote server... "something" happens between squid and the
remote server that stops the sending short. The client sends the
entire file to squid.

> AFAIK popups only occur when the client gets sent two re-auth
> challenges. Which in the un-patched Squid was caused by the first
> half-authenticated link being closed by Squid before auth could
> complete. Then the second link being challenged for more auth would
> cause popup.
>

Yes, that is what we were seeing unpatched.

> I think the next step is to find out what the difference between your
> two setups is exactly:
> * squid.conf

Here is a lightly edited squid.conf - just removed some acls that
should not affect the upload:

http_port 3128
cache_mem 32 MB
maximum_object_size 16000 KB
cache_dir aufs /cache 15000 16 256
cache_dir aufs /cache2 15000 16 256
cache_access_log /cache/logs/access.log
cache_log /cache/logs/cache.log
cache_store_log none
pid_filename /var/run/squid.pid
auth_param basic children 5
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 2 hours
request_header_max_size 10000 KB
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern . 0 20% 4320
acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl to_localhost dst 127.0.0.0/8
acl SSL_ports port 80 443 444 563
acl Safe_ports port 80 81 82 21 443 444 563 70 1025-65535
acl CONNECT method CONNECT
acl threat dstdomain "/opt/local/squid/etc/block_list.txt"
acl Safe_ports port 86
acl Safe_ports port 554
icp_access deny all
http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access deny threat
http_access allow all
http_access deny all
http_reply_access allow all
icp_access allow all
miss_access allow all
always_direct allow all
never_direct deny all
snmp_access deny all
coredump_dir /cache/logs

> * headers between Squid and the POSTing app.
> * headers between Squid and the web server.
>

I have these and will send them off list. As I mentioned before it
seems like the entire file is not being sent to the server for some
reason. I don't understand enough to tell if this is because the
server is terminating the connection early or squid is sending
something it does not like.

>
> If as you say the patch solved the issue but you saw the same thing
> earlier. Then I suspects it's probably a squid.conf detail being overlooked.
>

If I understand Bill correctly I think we are both getting the same
thing. I have not tested smaller files again since the patch but the
response to large file uploads is consistent with what I am seeing.

-- 
Brett Lymn
"Warning:
The information contained in this email and any attached files is
confidential to BAE Systems Australia. If you are not the intended
recipient, any use, disclosure or copying of this email or any
attachments is expressly prohibited.  If you have received this email
in error, please notify us immediately. VIRUS: Every care has been
taken to ensure this email and its attachments are virus free,
however, any loss or damage incurred in using this email is not the
sender's responsibility.  It is your responsibility to ensure virus
checks are completed before installing any data sent in this email to
your computer."