Bug in IE?

One day, I found myself debugging a very wierd situation with a CGI script that I was maintaining. The CGI script processes Chinese characters, and only on very rare occasion that it fails mysteriously. I double and triple-checked for all possible error handling, to no avail. After spending many hours, I decided that the problem only surfaces under Internet Explorer (my version is 6.0) and when a HTML form has the multipart/form-data enctype attribute, and one of the textfields in it contains the character . When the form is submitted, IE would send the HTTP request, but with the first CGI parameter corrupted.

I tried submitting a problem report to Microsoft here, but all I got after filling in the tedious form, is this:

We’re sorry, we were unable to service your request. As an option, you may visit any of the pages below for information about Microsoft services and products.

I tried submitting again today and the same thing happened. So I decided to post it here.

You can test if your version of IE has this bug by going to http://dready.org/cgi-bin/iebug.pl and submitting the form.
If you could let me know your results by posting a comment here, that’d be great.

10 Responses to “Bug in IE?”

  1. Livsey.org Says:

    I’ve been bitten by this bug this evening.
    Adding enctype=”multipart/form-data” to a form on a system I’m working on causes IE to mangle the first part of POST data sent to the server.
    It doesn’t happen on all pages, just a certain number which are p…

  2. Grant Says:

    I just found the same bug with some German characters. I worked around it by padding an extra field on top of the form: <input type=”hidden” name=”ieHasBugs” value=”true”>

  3. CC Says:

    I ran into a similar problem today with one of our multipart forms, although it did not seem to require any particular character to be in the form data.

    Instead, cutting and pasting data into a textarea seemed to be the deciding factor – if we typed the data manually, the data would come through clean. If we cut and pasted into the text area, the first form field would not get submitted to the server.

  4. Rainer Says:

    A friend of mine runs in the same problem last week. At first it was not clear, why and when this bug happens. After quite some tests and with the test on this website we could find the correlation in the forms and input data which leads to the bug.
    When you submit some special caracters in a textfield, the first transmitted field is corrupted IF the last transmitted field is NOT set (like unchecked checkbox). If the last transmitted field IS checked, than is the complete stream correctly transmitted. So if you send a hidden field as last (which means that the last field is always set), the transmission is always correct (especially the first field), even when using special caracters in textboxes.

  5. Hugo Says:

    Thanks for the info and research guys, I had the same problem. Keep up the good work.

  6. Anonymous Says:

    Thank you very much. It took me a day to figure out what was actually happeining :-(

  7. Asi Oppenheimer Says:

    Thank god for this blog, probably has saved me hours of debugging / Google searching, adding a dummy hidden field as the first one in the form seemed to have solved the problem. Did any of you guys found information about this bug in other places on the net?

  8. Charles Martin Says:

    Yeap, I confirm the conditions where this happens : Pasted code in an textarea (HTMLArea field here) which contained special characters (\222 => Word’s “‘”, empty checkbox as last field and the first one doesn’t get back to the server with IE. Adding another hidden field precisely named IEBug 😉 as first field solves this correctly. Thanks alot guys !

  9. Asi Oppenheimer Says:

    For me it was FCKEditor area to which text was paste, perhaps the rich text editors are one condition for this bug to occur?

  10. =cnd Says:

    Fails in IE6
    Works OK now in IE7
    nb: IE7 has unicode URLs supported – might fail in IE7 with this turned off perhaps?