large form post fails - IE patch bug?

[Charles Wallace]

My company has an application that embeds IE. After a recent automatic IE
update/patch (?), if the amount of data posted from a form is larger than
some limit, something messes up and the http POST message is not handled
correctly. The cutoff seems to be a content-length of about 1000 bytes.

When the IE option "Show friendly http error messages" is off, the POST
request is usually submitted twice. The http header for the 2nd POST is
formatted differently from the first, but equivalent. When this happens,
sometimes the followng redirect happens, but the browser state is messed
up - some frames not showing.

When IE option "Show friendly http error messages" is on, something stops
before the 2nd submit and no redirect happens.

We have a win 2000 system that runs the same code without problems. We have
2 XP systems that used to work, perhaps a month ago, but now both have this
problem, even running the same code that used to work.. They have not been
upgraded to XP SP2, but the automatic IE update option was on. I suspect
Q831167. It appears in the IE about box, but not in the control panel
add/remove list, so I'm not sure how to remove it.

I tried submitting the large form to the following test server at the Univ
of Texas - it simply returns the posted content. This bypasses my code that
usually receives and processes the code. This worked correctly, so clearly
IE is capable of submitting a form this large (content-length: 2628).
<FORM ACTION="http://www.utexas.edu/teamweb/cgi-bin/generic.cgi"
METHOD=POST>

Suggestions?

Thanks!!!!!!!!!!!!!!

 

[Robert Aldwinckle]

Suggestions?

Try a Developer's newsgroup. E.g. from MSDN online
click on Newsgroups and choose (e.g.) Web Development.
I'm not sure where to go from there. This newsgroup is mostly
for discussing IE's UI and error recovery issues.

I suspect Q831167.

Are you going just by the version of wininet.dll?
Do you have the latest cumulative security update: 867801?

The article indicates the problem was only associated with https
connections. Is that still the case?

Do you have control over the server to try the circumventions
re: Keep-Alive that article suggests?


BTW I don't understand what we should do with that FORM tag.
I am prepared to test for you but only if I don't have to do some coding.


HTH

Robert Aldwinckle