IE6 bug: doesn't resend form-data when server resets connection

[Guest]

Summary
-------

When the server closes the connection on a socket where IE is currently
sending a HTTP POST, IE will resend the request on a new socket, but will
only send the HTTP headers and not the form-data. (Seen when POST uses
multipart/form-data.)

Description
-----------

We are sometimes experiencing strange IE behaviour when surfing on webapps
on our application servers. Recently I was lucky to capture the network
traffic at one of these incidents, and it looks like IE's handling of
server-initiated connection closing/reset is broken.

In our example I submit a web form using POST and multipart/form-data. IE
sends the request on an existing socket and the server immediately replies
with a FIN reply to close the socket. IE continues to send on the socket
so the server finally resets the connection.
IE then automatically opens a new socket and successfully resends the
request, but leaves out the form-data and only sends the headers.

This is what the original request looks like (corresponding to the POST
beginning in packet 1 below, 5 packets in total), some headers and data
left out:

=========================================================================
POST /protected/editStudy.do HTTP/1.1

Content-Type: multipart/form-data;
boundary=---------------------------7d512c1b60e04

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR
1.0.3705; .NET CLR 1.1.4322)

Content-Length: 4678

Connection: Keep-Alive

Cookie: <snip>


-----------------------------7d512c1b60e04

Content-Disposition: form-data; name="editObjectChanged"



true

-----------------------------7d512c1b60e04

<snip...>
-----------------------------7d512c1b60e04

=========================================================================

This is what the resent request looks like (corresponding to the POST
beginning in packet 19 below, 1 packet in total):

=========================================================================
POST /protected/editStudy.do HTTP/1.1

Content-Type: multipart/form-data;
boundary=---------------------------7d52262c60e04

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR
1.0.3705; .NET CLR 1.1.4322)

Content-Length: 4678

Connection: Keep-Alive

Cookie: <snip>

=========================================================================

As can be seen the form-data is not sent and after a 30 sec timeout the
server responds with a timeout error as it isn't getting the promised 4678
bytes.

The Ethereal capture from the client's network interface is seen below.
It has been split up per socket used (the socket on port 1184 is included
at the end for clarity even though it doesn't seem to be related to the
POSTing)

First POST from client socket on port 1183, server wants to close the
connection but IE keeps sending. Server finally resets the connection:
No. Time Src Dest Prot Info
1 0.000000 cli srv HTTP POST /protected/editStudy.do HTTP/1.1
(cliport 1183)
4 0.000811 srv cli TCP http > 1183 [FIN, ACK] Seq=0 Ack=890
Win=18120 Len=0
5 0.000912 cli srv TCP 1183 > http [ACK] Seq=890 Ack=1 Win=63492
Len=0
6 0.002693 cli srv HTTP Continuation (cliport 1183)
7 0.002992 cli srv HTTP Continuation (cliport 1183)
8 0.003268 srv cli TCP http > 1183 [RST] Seq=1 Ack=1630252331
Win=0 Len=0
9 0.003329 cli srv HTTP Continuation (cliport 1183)
10 0.003437 cli srv HTTP Continuation (cliport 1183)
11 0.003535 srv cli TCP http > 1183 [RST] Seq=1 Ack=1630252331
Win=0 Len=0
12 0.003836 srv cli TCP http > 1183 [RST] Seq=1 Ack=1630252331
Win=0 Len=0
13 0.003918 srv cli TCP http > 1183 [RST] Seq=1 Ack=1630252331
Win=0 Len=0

IE resends POST from client socket on port 1242, form-data is missing and
the server returns error after 30 secs:
No. Time Src Dest Prot Info
16 0.016378 cli srv TCP 1242 > http [SYN] Seq=0 Ack=0 Win=64512
Len=0 MSS=1460
17 0.016563 srv cli TCP http > 1242 [SYN, ACK] Seq=0 Ack=1 Win=5840
Len=0 MSS=1460
18 0.016679 cli srv TCP 1242 > http [ACK] Seq=1 Ack=1 Win=64512 Len=0
19 0.018473 cli srv HTTP POST /protected/editStudy.do HTTP/1.1
(cliport 1242)
20 0.018881 srv cli TCP http > 1242 [ACK] Seq=1 Ack=891 Win=7120
Len=0
21 30.549929 srv cli HTTP HTTP/1.1 500 Internal server Error (cliport
1242)
22 30.667116 cli srv TCP 1242 > http [ACK] Seq=891 Ack=141 Win=64372
Len=0
23 30.667414 srv cli HTTP Continuation (cliport 1242)
24 30.668228 cli srv TCP 1242 > http [FIN, ACK] Seq=891 Ack=583
Win=63930 Len=0
25 30.668491 srv cli TCP http > 1242 [FIN, ACK] Seq=583 Ack=892
Win=7120 Len=0
26 30.668646 cli srv TCP 1242 > http [ACK] Seq=892 Ack=584 Win=63930
Len=0

Another socket apparently open on port 1184 that gets closed by the server:
No. Time Src Dest Prot Info
2 0.000566 srv cli TCP http > 1184 [FIN, ACK] Seq=0 Ack=0
Win=17030 Len=0
3 0.000788 cli srv TCP 1184 > http [ACK] Seq=0 Ack=1 Win=64172 Len=0
14 0.005090 cli srv TCP 1184 > http [FIN, ACK] Seq=0 Ack=1
Win=64172 Len=0
15 0.005265 srv cli TCP http > 1184 [ACK] Seq=1 Ack=1 Win=17030 Len=0

I'd be greatful for any comments or clarifications from people having
insight in issues like this.
Mike Wilson

 

[Robert Aldwinckle]

Summary
-------

When the server closes the connection on a socket where IE is currently
sending a HTTP POST, IE will resend the request on a new socket, but will
only send the HTTP headers and not the form-data. (Seen when POST uses
multipart/form-data.)

Q: In case your maintenance level is a factor which versions do you
have of the following modules: wininet.dll, urlmon.dll

Examples:

<title>KB831167 - You cannot log on to a Web site or complete an Internet transaction, or you receive an HTTP 500 (Internal Server
Error) Web page</title>

<title>KB319792 - Back Navigation on POST Causes Re-POST in Internet Explorer 6</title>


(TechNet search for:
post form kbie6*
)


Actually that description sounds familiar to me...

<title>KB305217 - Page Cannot Be Displayed Error During SSL 3.0 Server Session Timeout</title>

(TechNet search for:
kbwin* "keep-alive"
)

.... so, it was another example of a wininet.dll hotfix I was thinking off.
Note though that this was supposedly fixed in Win2kSP4.


FWIW

Robert Aldwinckle
---

 

[Guest]

Hi Robert, many thanks for your reply!

Q: In case your maintenance level is a factor which versions do you
have of the following modules: wininet.dll, urlmon.dll

wininet.dll: ver 6.0.2800.1405, size 588288, date 2004-feb-6
urlmon.dll: ver 6.0.2800.1408, size 485376, date 2004-feb-27

KB831167 - You cannot log on to a Web site or complete an Internet
transaction, or you receive an HTTP 500 (Internal Server Error) Web page

Spot on!
(I had actually searched in KB myself but apparently used the wrong search
terms, sorry about that.)

Everything fits perfectly with what we have been seeing, and from the info on
this bug I can now reproduce the it every time. The appservers I mentioned
are Weblogic 8.1 and they have a default KeepAlive timeout of 30 secs.
IE holds on to keepalive'd sockets for 60 secs and due to this bug I get the
error if I submit a POST to the server 30-60 secs after the last access (that
is while IE tries to send on a socket that the server has already discarded).
Below 30 secs and above 60 secs everything works fine.
If I adjust the KeepAlive timeout on WLS to 70 secs the problem goes away.

.... so, it was another example of a wininet.dll hotfix I was thinking off.
Note though that this was supposedly fixed in Win2kSP4.

Yes, this is strange. I can see in KB831167 that I actually already have the
corrected version of wininet.dll and the About box in IE also tells me the
KB is installed - the version reads:
SP1; Q810847; Q832894; Q837251; Q831167; Q823353
And yes, my system reports Win2KSP4 is installed.

So, does this tell us that the bug is back in business?
(Hm, will the existence of this post alert MS of the problem?)
Mike

 

[Robert Aldwinckle]

Hi Robert, many thanks for your reply!



wininet.dll: ver 6.0.2800.1405, size 588288, date 2004-feb-6
urlmon.dll: ver 6.0.2800.1408, size 485376, date 2004-feb-27


Spot on!
(I had actually searched in KB myself but apparently used the wrong search
terms, sorry about that.)

Everything fits perfectly with what we have been seeing, and from the info on
this bug I can now reproduce the it every time. The appservers I mentioned
are Weblogic 8.1 and they have a default KeepAlive timeout of 30 secs.
IE holds on to keepalive'd sockets for 60 secs and due to this bug I get the
error if I submit a POST to the server 30-60 secs after the last access (that
is while IE tries to send on a socket that the server has already discarded).
Below 30 secs and above 60 secs everything works fine.
If I adjust the KeepAlive timeout on WLS to 70 secs the problem goes away.


Yes, this is strange. I can see in KB831167 that I actually already have the
corrected version of wininet.dll and the About box in IE also tells me the
KB is installed - the version reads:
SP1; Q810847; Q832894; Q837251; Q831167; Q823353
And yes, my system reports Win2KSP4 is installed.

So, does this tell us that the bug is back in business?
(Hm, will the existence of this post alert MS of the problem?)

Why aren't you at the current level of cumulative security update?
In addition to getting higher level versions that way you could also
install the hotfix rollup version 889669 and then get the hotfix
integrated versions of the modules involved. Note that cumulative
security updates after MS04-004 no longer integrate hotfixes
unconditionally; so in order to get hotfixes integrated you have to
deliberately install them. Once they're installed though you supposedly
would get the hotfix integrated version of a cumulative security update.

For example, the fact that you already have a hotfix version of wininet.dll
(from 831167) may mean that if you installed 867282 (MS05-014,
currently, according to the Security Bulletin Search Tool the latest
cumulative update for IE6sp1) you would get 6.0.2800.1486
instead of 6.0.2800.1485. and whatever integrated hotfixes it
now contains. E.g. perhaps a fix for your Keep-alive issue. Etc.


HTH

Robert
---

 

[Mike Wilson]

Oops, by accident the last "n" in the subject was deleted so a
couple of continuing posts are found in a Usenet thread titled:

"IE6 bug: doesn't resend form-data when server resets connectio"

Mike

 

[Guest]

Why aren't you at the current level of cumulative security update?

Good question Here's a couple of clues:
- multinational company
- standardized environment applied to thousands of clients
- IS department outsourced to IBM
;-)

In addition to getting higher level versions that way you could also
install the hotfix rollup version 889669 and then get the hotfix
integrated versions of the modules involved. Note that cumulative
security updates after MS04-004 no longer integrate hotfixes
unconditionally; so in order to get hotfixes integrated you have to
deliberately install them. Once they're installed though you supposedly
would get the hotfix integrated version of a cumulative security update.

For example, the fact that you already have a hotfix version of wininet.dll
(from 831167) may mean that if you installed 867282 (MS05-014,
currently, according to the Security Bulletin Search Tool the latest
cumulative update for IE6sp1) you would get 6.0.2800.1486
instead of 6.0.2800.1485. and whatever integrated hotfixes it
now contains. E.g. perhaps a fix for your Keep-alive issue. Etc.

Ok, I'll try to find a client where I'm allowed to muck around with updates.
Do you recommend that I try with only installing 867282 first, or that I
install both 889669 and 867282 straight away?

Just to confirm with you: our issue should already have been corrected as I
have the 831167 (but it isn't) so now we will be testing with the latest
and greatest stuff to see if it's ok there?

Cheers
Mike

 

[Robert Aldwinckle]

....

Ok, I'll try to find a client where I'm allowed to muck around with updates.
Do you recommend that I try with only installing 867282 first,
or that I install both 889669 and 867282 straight away?

Depends what you want. 889669 seems to be *all* hotfixes integrated
in *all* modules -- the "bleeding" edge of maintenance. <eg>

I was suggesting as a test of the new hotfix integration procedure
for cumulative updates that you could try installing 867282 and
see if you really did get the latest hotfixed version of wininet.dll
because of your existing 831167 version.

I don't know how independent those modules might be
but if they are completely independent another option
would be to download the 867282 package, expand it
and extract only the hotfixed version of wininet.dll
and try that.

Just to confirm with you: our issue should already have been corrected as I
have the 831167 (but it isn't) so now we will be testing with the latest
and greatest stuff to see if it's ok there?

Yes. I think if you went to Support they would ask if you
had tried the latest and greatest first anyway.


Good luck

Robert
---

 

[Robert Aldwinckle]

Oops, by accident the last "n" in the subject was deleted so a
couple of continuing posts are found in a Usenet thread titled:

"IE6 bug: doesn't resend form-data when server resets connectio"

Mike

That's fine. They are all properly threaded using the References:
header in OE. MS web interface to newsgroups sees them all
in one "discussion" too.

http://www.microsoft.com/windows/ie...f7ba&mid=0b17d4b7-9e4e-4eaf-bdc0-2181d7bf068d


Does Google Groups not thread them? <eg>

http://groups-beta.google.com/group...:microsoft.*.ie6.browser#doc_8d78287062fb9897

(Google Groups search for
author:wilson "keep-alive" group:microsoft.*.ie6.browser
)


Nope. It's got them too. Not a problem anywhere


Robert
---

 

[Guest]

http://groups-beta.google.com/group...:microsoft.*.ie6.browser#doc_8d78287062fb9897

I was actually thinking of the users of the non-beta Google Groups (that
I tend to use a lot myself):
http://groups.google.com/groups?q=ie6+bug+resend+"mike+wilson"
as two distinct threads are shown there.

Interesting with the beta-version though, didn't know about that!

Cheers
Mike

 

[Guest]

http://groups-beta.google.com/group...:microsoft.*.ie6.browser#doc_8d78287062fb9897

I was actually thinking of the users of the non-beta Google Groups (that
I tend to use a lot myself):
http://groups.google.com/groups?q=ie6+bug+resend+"mike+wilson"
as two distinct threads are shown there.

Interesting with the beta-version though, didn't know about that!
(And it is actually Microsoft's web-based newsreader that keeps cutting
off the trailing "n" in the title

Cheers
Mike

 

[Guest]

....

I was suggesting as a test of the new hotfix integration procedure
for cumulative updates that you could try installing 867282 and
see if you really did get the latest hotfixed version of wininet.dll
because of your existing 831167 version.

Sounds fair, could be interesting to see if it works. If I don't get the
new version I'll go for the specific update.
I'm getting a "muckable" client on Monday so will try it out then!

I don't know how independent those modules might be
but if they are completely independent another option
would be to download the 867282 package, expand it
and extract only the hotfixed version of wininet.dll
and try that.

I actually already looked at that but I only found a wininet.dll_p
that didn't expand into anything useful so I was guessing it was
some kind of delta-file. (To be correct, in a subdirectory I also
found a wininet.dll of the same version as is already on my
system.)

Good luck

Robert

Thanks for all the help. Have a nice weekend!
Mike

 

[Mike Wilson]

Sounds fair, could be interesting to see if it works. If I don't get the
new version I'll go for the specific update.
I'm getting a "muckable" client on Monday so will try it out then!

I have now tried 867282 (which didn't update wininet.dll) and then 889669
(which didn't update it either) so after the two installs I am still at
version 1485 of wininet.dll and the problem remains.
Unfortunately Windows Update is blocked for the whole site so I can't just
go and grab the lot to see what happens...

Any ideas?
Thanks / Mike

 

[Robert Aldwinckle]

I have now tried 867282 (which didn't update wininet.dll) and then 889669
(which didn't update it either) so after the two installs I am still at
version 1485 of wininet.dll and the problem remains.
Unfortunately Windows Update is blocked for the whole site so I can't just
go and grab the lot to see what happens...

Any ideas?

Looks as if the version that you have is no longer recognized
as a hotfix. (Makes sense since that is the version that 867282
is offering as a non-hotfixed security patch; i.e., Folder == RTMGDR.
Sorry I didn't notice that.) I was hoping that one of the procedures
would give you the RTMQFE version, 6.0.2800.1486.

You could try expanding the patch package and extracting that version
and testing it.

Here are two more considerations if your tests still fail after that:

Notice that wininet.dll is one of the unusual modules which has
a DllInstall entry point but doesn't have a DllRegisterServer.
Hence, if you need to register it you would have to use this syntax:

regsvr32 /n /i wininet.dll

Also I would monitor its registry accesses with SysInternals RegMon.
Sometimes the functionality implied by hotfixes after they are RTM
is not active by default and only provided after a registry switch is set
which explicitly Oks a new behaviour.


Good luck

Robert
---

 

[Robert Aldwinckle]

Oops sorry, I mistook an "8" for a "0" there. I have rerun the the tests
and here is the correct story:

1. Our default client has wininet.dll 6.0.2800.1405.

So they have the hotfix? How did they get it?
Did you try checking if there is a registry switch required
to activate the hotfix functionality?

2. Installing 867282 gives me wininet.dll 6.0.2800.1485.

But it appears that you don't have the hotfix? If you had the hotfix
we would have expected you to get 6.0.2800.1486 instead.

3. Installing 889669 keeps me on wininet.dll 6.0.2800.1485.
Ditto.



With "1485" the problem still remains.

Probably, (we assume) because the hotfix is still not integrated
into the non-hotfix RTM version of the security update.

I have unpacked the hotfix archives but haven't been able to find any
"1486" version.

Hmm... how did you do that? I just noticed that the bulletin doesn't
advertise an expand procedure any more.

Perhaps you have to do it with AU?

FWIW here is what I still have after an AU install on my XPsp1 partition:

G:\WINDOWS\SoftwareDistribution\Download\64a79cf0f12e33eb879c32f446d6e441\RTMQFE>filever wininet.dll
--a-- W32i DLL ENU 6.0.2800.1486 shp 581,120 12-07-2004 wininet.dll

Note that I don't have this installed either. I'm just pointing out how
it may be possible to copy it so you can install it and test with it, etc.


BTW notice that now there is an even later version of wininet.dll
you could get from the RTM version of the *new* cumulative update.

<title>Microsoft Security Bulletin MS05-020: Cumulative Security Update for Internet Explorer (890923)</title>
http://www.microsoft.com/technet/security/Bulletin/MS05-020.mspx

<quote>
Wininet.dll 6.0.2800.1497 18-Feb-2005 20:45 581,632
</quote>

So, if nothing else works for you, based on my example you could use
AU to download and install the new one and then copy the RTMQFE
version from its Download subdirectory (assuming you're not using
WUv4 <eg>. I can't remember where it puts stuff when it installs updates.
I seem to recall though that expanded files were much more transient
with it. E.g. you might have to use FileMon to notice where they go and
hope for a prompt to allow you a chance to copy one before the update
deleted them all as part of a finishing cleanup. Etc.)


Good luck

Robert
---

 

[Guest]

[Back from vacation]

Did you try checking if there is a registry switch required
to activate the hotfix functionality?

No, I didn't do that. Sorry.

Hmm... how did you do that? I just noticed that the bulletin doesn't
advertise an expand procedure any more.

I expanded the IE6.0sp1-...exe using WinZip and then looked in the rtmgdr
folder where there are some dlls, including wininet.dll.
(In the root folder of the update there is also a wininet.dll._p which I
guess is a patch file to use on the complete file.

Perhaps you have to do it with AU?

Everything regarding Windows Update is locked down at our site, including
windowsupdate.microsoft.com being stopped by the firewall.

BTW notice that now there is an even later version of wininet.dll
you could get from the RTM version of the *new* cumulative update.

Microsoft Security Bulletin MS05-020: Cumulative Security Update for Internet Explorer (890923)
http://www.microsoft.com/technet/security/Bulletin/MS05-020.mspx

Wininet.dll 6.0.2800.1497 18-Feb-2005 20:45 581,632

I tried installing this and it did upgrade my wininet.dll to the newest
version:

If only installing 890923 I get:
version: 6.0.2800.1496
date: 2005-02-18, 16:19:18
size: 592384

If first installing 889669 and then 890923 I get:
version: 6.0.2800.1497
date: 2005-02-18, 22:45:03
size: 581632

But the problem still remains. I guess we have an unfixed bug here. (I
tried Firefox on the same client and it works fine.)
I tried to get the bug reported by our IS department but apparently they
have to pay Microsoft for reporting bugs so they were not so interested.

Cheers Mike

 

[Robert Aldwinckle]

....

If first installing 889669 and then 890923 I get:
version: 6.0.2800.1497
date: 2005-02-18, 22:45:03
size: 581632

But the problem still remains. I guess we have an unfixed bug here. (I
tried Firefox on the same client and it works fine.)
I tried to get the bug reported by our IS department but apparently they
have to pay Microsoft for reporting bugs so they were not so interested.

Cheers Mike

Well, at least make sure that you report it somehow.

Hmm... I have been told to use the Help, Send Feedback menu item.
(in IE: Alt-H,k). That page does have a link labeled:
Report a Microsoft product bug
http://support.microsoft.com/gp/contactbug
but it leads to a page which just lists a 1-800- number
which is where you would probably be challenged to open a support
incident, not just document the bug. I wouldn't want to try to document
a bug over the telephone anyway.

I'll have to research this some more.


BTW there is a new article out which I wasn't aware of when this
thread started:

<title>How to install hotfixes that are included in cumulative security updates for Internet Explorer 6 Service Pack 1</title>
http://support.microsoft.com/default.aspx?scid=kb;en-us;897225


FYI

Robert
---

 

[Guest]

Thanks again for your respone

Well, at least make sure that you report it somehow.

I sure will try...

I'll have to research this some more.

On a side note I found the following behavioral differences between
how Weblogic and Apache handles closing of kept-alive sockets:

Weblogic with keep-alive timeout 30 secs:
socket 1
Time 00 : User navigates : IE POST request -> WLS, WLS HTML -> IE
Time 30 : Socket times out : (no network traffic)
Time 45 : User navigates : IE POST request -> WLS, WLS TCP_FIN -> IE
socket 2
Time 45 : : IE resends POST request without form-data

Apache with keep-alive timeout 15 secs:
socket 1
Time 00 : User navigates : IE POST request -> Apache, Apache HTML -> IE
Time 15 : Socket times out : Apache TCP_FIN -> WLS
socket 2
Time 45 : User navigates : IE POST request -> Apache, Apache HTML -> IE

To summarize, IE handles Apache well as Apache sends a TCP FIN telegram
(to close the connection) as soon as the kept-alive socket times out.
Therefore IE never tries to reuse the socket but instead starts on a
fresh one on the next navigation and a resend is never necessary.

Weblogic, on the other hand, doesn't send the TCP FIN (connection close)
telegram until IE actually tries to use the connection even though it
timed out 15 seconds earlier. In this case IE needs to resend the POST
request and this is when the form-data is forgotten.

Maybe the bug described in KB831167 was really fixed, but only for
systems behaving like Apache...?

<title>How to install hotfixes that are included in cumulative security updates for Internet Explorer 6 Service Pack 1</title>
http://support.microsoft.com/default.aspx?scid=kb;en-us;897225

Thanks, I actually bumped into this one yesterday.

Mike