for those of you really interested in this, I found myself about IE8 not handling as expected <form class="simple" enctype="multipart/form-data" method="post">, (likely a bug) while studying module "02 | Writing
for Absolute Beginners" "MVA" course when I too reached ‘Validator.nu
(X)HTML5 Validator (Living Validator)‘ site and made this very basic test :
1) selected ‘Text Field’ for ‘Validator Input’, 2) left default HTML5 code unchanged, 3) pressed [ Validate ] button.
After I received unexpected message :
HTTP ERROR 415
Problem accessing /. Reason:
application/x-www-form-urlencoded not supported. Please use multipart/form-data
After I made some more investigations and I found out that :
– using IE8 Developer Tools, after selecting involved HTML code (<form class="simple" enctype="multipart/form-data" method="post">) on left pane HTML and selecting Attributes in right pane and ‘Show read-only
properties’ near its lower edge, it’s possible to find main evidence of issue.
Because of resulting error message displayed and reported above, it seems that ‘encoding’ read-only property, whose line is listed right above ‘enctype’ line by IE8 Developer Tools (whose
new support introduced by IE8 and is backward compatible with ‘enctype’ itself), is also predefined but with value ‘application/x-www-form-urlencoded’ instead, it seems to be used by IE8 (and quite likely by IE9 too) even if already in Standards Mode
because of <!DOCTYPE html> directive. So from results it’s like the post is forced using ‘encoding’ backward compatible read-only property value instead of expected "multipart/form-data" property defined by ‘enctype’.
At least now I can also confirm that IE10 on Windows 7 Ultimate SP1 already definitely solves this issue when repeating same test and for both ‘encoding’ (predefined read-only property) and ‘enctype’, values shown by IE10 Developer Tools always corresponds
to expected "multipart/form-data".
P.S. But because I believe MSHTML.DLL handles "multipart/form-data" and because my IE8 still with issue already had latest KB2964358 (MS14-021)
installed, I assume that a new bug for IE8 and maybe IE9 should be opened to possibly definitely fix this effect too, if in future any newer QFE MSHTML.DLL should ever see the light to become public.