Socket Closing and IE Browser problems? Microsoft/MVP please provide some feedback

[Hector Santos]

While trying to address a customer IE browser problem I came across an
additional IE issue which may be related. I need some input from Microsoft
and/or MVP people. Please provide some feedback if you can.

To make this easy, I have prepared test web server that you can use to
test to see if you duplicate the problem. This will display a FORM with one
textarea field.

http://www.winserver.com/public/code/html-ietest4

Detail Description:

1) A customer reported IE has been issuing a response "Page Cannot be
Displayed" related to the size of the posted form field. I am trying to
help him figure it out. If you do a google newsgroup search on this exact
worded error, you will see it is something that is happening to many in
recent weeks, so I don't think it is exclusive to our particular intranet
web server.

However, I don't believe this is related to some of resolutions posted on
internet. This is not a IIS web server and it is not limited by the size of
a posted form field as indicated by the following Microsoft KB for the IIS
web server:

http://support.microsoft.com:80/support/kb/articles/Q273/4/82.ASP&NoWebContent=1

Nonetheless, I am not sure if this is a IIS web server limitation or a IE
form field post limitation.

2) In testing the customer report which I personally can't repeat #1 (I
don't get the "page cannot be displayed" error), I can repeat another
behavior where IE will automatically reissue a POST command and a GET
command after an initial POST command was done.

To repeat this problem, all you need to do is fill in a form textarea field
with X amount of data.

In my test case, when X is around 7300+ bytes, the server sends back the
response and the browser reissues the POST and then the same URL as a GET.

My customer is seeing a "Page Cannot be displayed" instead.

I believe #2 is related to some "IE issue" with Socket Closing, Linger
support and Network transmission.

A) Behavior #2 does not occur in both the client and server on the local
machine. I can only repeat this across a TCP/IP network.

B) If I turn off Linger in my web server, behavior #2 does not occur,
however, only partial HTTP response is displayed. This is expected. But
more importantly, not reissuing of the URL is sent.

This kind of tells me, that IE has a problem with a socket closing and not
finishing up a lingering READ on the socket. It is like if IE is reading
the socket data, but then it is pre-empted with a Socket Close, so it
retries by sending the request again. Not sure, but that what it seems
like it is doing.

I will appreciate any feedback, if not, thanks anyway.

Again, to make it easy, I prepare a temporary test web server setup that
you can try out to see if you an duplicate the problem with your browser:

http://www.winserver.com/public/code/html-ietest4

This will display a form that you can use to test how much data can be
posted and how much your IE browser can receive back to redisplay. If you
get a PAGE CANNOT BE DISPLAY, you are duplicating my customer's problem
with his copy IE. If you get the reissuing of the URL posting, you are
duplicating what I am seeing.

thanks

 

[Hector Santos]

Thanks for NOTHING! Over 50 or so people tried this and not one FREAKING
FEEDBACK!

Geez! What a helpful GROUP!?

It really leaves a bitter taste in your mouth when Microsoft or a MVP can't
provide some FEED BACK. I even left a email address on the URL for
direct/personal feedback if you wanted to keep a private dialog going.

Microsoft and MVP people: SHAME ON YOU!

I am convinced now this is a IE Bug. It is not supporting RFC 793, RFC
1122.

A web host needs to compensate for the IE BUG by doing two things:

1) Throttle the sending of data (slow it down)
2) Add a small sleep before issuing a shutdown(socket,SD_SEND);
closesocket(socket)

That is how you solve the "PAGE CANNOT BE DISPLAYED" problem or URL
refreshing problem only exhibited by the IE BROWSER. No other browser shows
this behavior.

I challenge anyone to show me this is indeed a bug in the web host. The
throttle is an option, not a requirement, and the small delay (Sleep(300) is
certainly not a requirement. This tells me the IE socket usage is
faulty.

 

[Jone Doe]

Thanks, that will certainly endear you to the group and get you many
replies.

Keep in mind that Microsoft may or may not monitor this group. All replies
are coming from unpaid volunteers, who just love mesages like yours.