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

Amos (or anyone)

I'm trying to marry up debug output with tcpdump traces taken on the squid box but I want greater precision. Is there a debug_options setting which will cause entries in cache.log to be timestamped in micro-seconds? If not, is there something I can change (in debug.c ?) to make that happen (bearing in mind I'm an absolute novice C coder)?

Bill A.

-----Original Message-----
From: vincent.blondel_at_ing.be [mailto:vincent.blondel_at_ing.be]
Sent: 22 December 2009 07:36
To: squid-users_at_squid-cache.org; squid3_at_treenet.co.nz
Cc: Bill Allison; vincent.blondel_at_ing.be
Subject: RE: [squid-users] any work arounds for bug 2176

 
Hello all,

Just to inform you I exactly get the same problem. Firstly I thought it
was a problem with WWW-Authenticate but it is not ONLY ....

next is the reference of my first post ...
http://www.squid-cache.org/mail-archive/squid-users/200912/0029.html

I also get this same message ( httpReadReply: Request not yet fully sent
) when sending some POST requests bigger than x bytes to an IIS server
...

I applied the patch from the bugzilla (2176) on a 2.7.4. The user does
not receive the traditional 'Page cannot be displayed' from Internet
Explorer any more but the browser freeze instead :(-

below the current config ...

client_persistent_connections on
server_persistent_connections on
acl protime url_regex -i ^http://services.group.intranet/rec
acl protime_src src all
cache_peer 1.2.3.4 parent 80 0 forceddomain=services.group.intranet
originserver proxy-only no-query no-digest connection-auth=on login=PASS
cache_peer_access 1.2.3.4 allow protime

I am certainly interested with a definitive solution so if I can be part
of the tests, just say it ...

many thks
Vincent.

-----Original Message-----
From: Bill Allison [mailto:bill.allison_at_bsw.co.uk]
Sent: Friday, December 18, 2009 10:47 AM
Cc: squid-users_at_squid-cache.org
Subject: RE: [squid-users] any work arounds for bug 2176

Reposted for info to the list, without the attachments that cause the
list to bounce the message

-----Original Message-----
From: Bill Allison
Sent: 18 December 2009 09:43
To: 'Amos Jeffries'; Brett Lymn
Cc: squid-users_at_squid-cache.org
Subject: RE: [squid-users] any work arounds for bug 2176

"I get the same error as Brett only when the body of the post is much
greater than that which causes the post to fail."

Correction after further testing...

I get the same error as Brett only when the body of the post is much
greater than that which causes the post to fail, and even then only
sometimes, in repeated tests with the same file being uploaded.

Other times the browser reports "The connection was reset" and tcpdump
shows that the proxy sent a FIN to the server then to the client in
response to the second 401 from the server. THe server closes the
connection but the client continues sending a POST and the proxy then
sends the client a string of RSTs.

For info "Invalid Verb" is issued by http.sys in IIS 6.0, in response to
receiving a header that is not strictly rfc-compliant (including
truncated).

Attached as requested is my squid.conf and tcpdumps of the Invalid Verb
and RST failure cases.

Unlike Brett I'm very much a novice C coder but I'm perfectly happy to
patch, compile and test if it helps generate a solution.

Regards
Bill A.

-----Original Message-----
From: Amos Jeffries [mailto:squid3_at_treenet.co.nz]
Sent: 17 December 2009 09:10
To: Brett Lymn
Cc: Bill Allison; squid-users_at_squid-cache.org
Subject: Re: [squid-users] any work arounds for bug 2176

Brett Lymn wrote:
> On Wed, Dec 16, 2009 at 07:57:21AM -0600, Bill Allison wrote:
>> Sorry - that was misleading. I've had
>> persistent_connection_after_error set on throughout my testing.
>
> I don't have that in my config file at all so I would guess it is at
> the default.
>

Which is off. Now I'm confused.

>> I get the same error as Brett only when the body of the post is much
greater than that which causes the post to fail.
>>
>
> I only tried a large-ish document. We did observe the same strange
> limit that Bill has seen when we tested without the patch applied,
> under a certain "magic" threshold the document would upload - the
> threshold seemed to be around the 50k mark, over that threshold we
> would just get popups.
>
>> I'd like to correlate network traces with debug output and would
>> appreciate suggestions as to which debug_options would include all
>> possibly relevant info
>>
>
> 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.

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.

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.

I think the next step is to find out what the difference between your
two setups is exactly:
  * squid.conf
  * headers between Squid and the POSTing app.
  * headers between Squid and the web server.

Particularly in what reply headers are going back. That should give us
a little more of an idea what areas to look at.

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.

Amos

--
Please be using
   Current Stable Squid 2.7.STABLE7 or 3.0.STABLE20
   Current Beta Squid 3.1.0.15
--
This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.
-----------------------------------------------------------------
ATTENTION:
The information in this electronic mail message is private and confidential, and only intended for the addressee. Should you receive this message by mistake, you are hereby notified that any disclosure, reproduction, distribution or use of this message is strictly prohibited. Please inform the sender by reply transmission and delete the message without copying or opening it.
Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-----------------------------------------------------------------
ING Belgium SA/nv -  Bank/Lender - Avenue Marnix 24, B-1000 Brussels, Belgium -  Brussels RPM/RPR - vat BE 0403.200.393 - BIC (SWIFT) : BBRUBEBB - Account: 310-9156027-89 (IBAN BE 45310-9156027-89). 
An insurance broker, registered with the Banking, Finance and Insurance Commission under the code number 12381A.
ING Belgique SA - Banque/Preteur, Avenue Marnix 24, B-1000 Bruxelles - RPM Bruxelles - tva BE 0403 200 393 - BIC (SWIFT) : BBRUBEBB - Compte: 310-9156027-89 (IBAN: BE 45310-9156027-89). 
Courtier d'assurances inscrit a la CBFA sous le no 12381A
ING Belgie nv - Bank/Kredietgever - Marnixlaan 24, B-1000 Brussel - RPR Brussel - btw BE 0403.200.393 - BIC (SWIFT) : BBRUBEBB - Rekening: 310-9156027-89 (IBAN: BE45 3109 1560 2789). 
Verzekeringsmakelaar ingeschreven bij de CBFA onder het nr. 12381A.
-----------------------------------------------------------------
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.