[squid-users] (104) Connection reset by peer GET or POST

From: Max Erixon <max.erixon@dont-contact.us>
Date: Mon, 9 Sep 2002 16:21:25 +0200

Aloha!

I have a problem. We have developed a web application which is hosted on two
domains (actually, also two hosting companies).

Quite often the client receive the following error:

ERROR
The requested URL could not be retrieved

----------------------------------------------------------------------------

----
While trying to retrieve the URL:
http://www.xxxxxx.com/nbs20/asp/register/ipc.asp? 
The following error was encountered: 
Read Error 
The system returned: 
    (104) Connection reset by peer
An error condition occurred while reading data from the network. Please
retry your request. 
Your cache administrator is support@xxxxx.com. 
----------------------------------------------------------------------------
----
Generated Mon, 09 Sep 2002 13:48:24 GMT by semaldns01.xxxxx.com
(Squid/2.4.STABLE4)
Which is generated by our proxy. I.e. this is what it looks like when we
recreate the error from within our domain. This error occurs when the client
posts a html form (http post) on one domain to a page on the other domain.
After reading the message
http://list.cineca.it/cgi-bin/wa?A2=ind0207&L=squid&D=0&P=94669 and the
following information in the configuration manual:
"When always_direct and never_direct are deny (By default), Squid selects
based on the 
request type and a number of other factors if a parent should be used or
not, and if a parent 
could not be reached it will always fallback on direct."
I tried to use http get instead in the form, after that it seems to work ok.
However now we experience the same problem when we are doing multiple posts
(http post) on one page in one of the domains. 
We have received complaints from our customers who receive the same error
and we are very eager to solve the problem.
How can I as a developer solve this problem? I can't do anything about the
Squid configuration. Should we only use http get instead of http post? There
must be another way around the problem from a developer perspective. 
Thanks!
Regards,
Max.
Received on Mon Sep 09 2002 - 08:21:34 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 17:10:10 MST