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

Brett Lymn wrote:
> 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.
>

I've taken a good look at the trace files on this. It's clear that the
client is in fact not sending the whole initial POST.

What I see happening is that the server early response gets relayed by
Squid and if the connection is not aborted Squid receives a small
further portion of data from the client before it abruptly stops and
starts sending the re-send POST with auth details.

Since the client has indicated a certain length X of data then only
sends N bytes the start of second request is lost and the server
complains that some random bytes mid-way down the repeat POST are an
invalid request method "verb".

To get this going we are going to have to add to the patch a bit to make
Squid delay the relayed reply until the initial POST is fully received.

PS: This has pushed Squid very, very close to the wanted behavior for
Expect-100 HTTP/1.1 requests/replies. Thanks guys.

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE7 or 3.0.STABLE20
   Current Beta Squid 3.1.0.15