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 Wed Sep 01 1999 - 00:33:17 MDT