RE: IE4 "hangs", with TCP_MISS/500||504, HTTP POST, and IIS.

Timothy/Alex,

Thanks for your help.

I've enabled anonymizing for User-Agent, but it doesnt seems to make much of
a difference. If I give it a blank fake useragent, or a Netscape user
agent, I still have the same problem.

Anybody else?

Thanks,

Chris
  

-----Original Message-----
From: Alex Rousskov
To: Timothy Litwiller
Cc: Chris McDonough; 'squid-users@ircache.net'
Sent: 9/1/99 2:22 AM
Subject: Re: IE4 "hangs", with TCP_MISS/500||504, HTTP POST, and IIS.

Your suggestion may defeat any browser-specific tricks that an origin
server (content provider) might have. If faking the user agent is the
only
solution, perhaps specifying a non-existent agent is safer and more
"polite" with respect to the origin server..

Alex.

On Wed, 1 Sep 1999, Timothy Litwiller wrote:

> try turning on the anonymizer function and putting in a Netscape user
aggent so
> that the server thinks it is talking to a netscape client and doens't
try to do
> ms-ms special mode.
>
> Chris McDonough wrote:
>
> > OK.
> >
> > Here's the situation... I've read the FAQ, researched the mailing
list
> > archives and DejaNews, et. al. We've got Squid 2.2-STABLE4 running
on Linux
> > 2.2.10 kernel. Users access all http, https, and ftp URLs through
this
> > single Squid proxy. All users run IE 4 (which rev, I dont know,
possibly
> > many revs). The problem:
> >
> > Certain HTML documents which contain POST forms (for example, the
> > subscription form at
> >
http://www.winntmag.com/OurProducts/Sub/Index.cfm?Action=Subscribe&Code=
99IN
> > XTUP, or for another example the "send" button used for a new
message under
> > MS Outlook Web Access) cause IE4 to "hang" (no error response from
Squid)
> > when the user presses the submit button. In the access.log, an
entry is
> > generated that looks something like:
> >
> > 936152282.992 901930 172.21.10.50 TCP_MISS/504 0 POST
> > http://www.winntmag.com/OurProducts/Sub/Index.cfm? -
DIRECT/www.winntmag.com
> > -
> >
> > OR
> >
> > 936152338.670 896169 172.21.10.50 TCP_MISS/500 0 POST
> > http://www.winntmag.com/OurProducts/Sub/Index.cfm? -
DIRECT/www.winntmag.com
> > -
> >
> > (note the difference is the return code - 500 vs 504, either is
returned,
> > same symptoms from user perspective, however).
> >
> > The problem does not happen when a user submits the form via
Netscape 4.5.
> >
> > A Netscape user's entry in access.log looks like:
> >
> > 936151112.151 700 172.21.10.50 TCP_MISS/302 450 POST
> > http://www.winntmag.com/OurProducts/Sub/Index.cfm? -
DIRECT/www.winntmag.com
> > text/html
> >
> > .. and the Netscape user is able to access the page generated by the
POST
> > request.
> >
> > The only other constant I've sort of been able to determine is that
the
> > server is always running IIS in the problem cases. In the case a
user of IE
> > submits a POSTed form to a server running, for example, Linux, the
POST
> > always works.
> >
> > Ugly. I wish it was even a remote option to suggest switching to
Netscape,
> > but its really not.
> >
> > The real kicker is that this problem did not surface under the
combination
> > of Squid 2.0 and Linux kernel version 2.0X (we only recently
upgraded the
> > proxy server to 2.2-STABLE4 and 2.2.10 from an older setup).
> >
> > Additionally, and I don't know if it's meaningful, but in cache.log,
we get
> > errors occuring every minute like this:
> >
> > 1999/08/31 23:28:06| clientReadRequest: FD 18 Invalid Request
> > 1999/08/31 23:29:06| clientReadRequest: FD 18 Invalid Request
> > 1999/08/31 23:30:07| clientReadRequest: FD 18 Invalid Request
> > 1999/08/31 23:31:07| clientReadRequest: FD 18 Invalid Request
> > 1999/08/31 23:32:07| clientReadRequest: FD 18 Invalid Request
> > 1999/08/31 23:33:08| clientReadRequest: FD 18 Invalid Request
> > 1999/08/31 23:34:08| clientReadRequest: FD 18 Invalid Request
> > 1999/08/31 23:35:08| clientReadRequest: FD 18 Invalid Request
> > 1999/08/31 23:36:09| clientReadRequest: FD 18 Invalid Request
> > 1999/08/31 23:37:09| clientReadRequest: FD 18 Invalid Request
> >
> > The filedescriptor number does change, but the error is constant,
this was
> > just a log snippet.
> >
> > Little help?
>
>
Received on Thu Sep 02 1999 - 09:27:17 MDT