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
