I wanted to add that the fact that browsers encode the field names in the page encoding does not change that they should escape the header according to RFC 2047.

The percent-encoding used in the field name has nothing to do with multipart/form-data or headers encoding or even html attribute value escaping. There's no reason for Chrome to percent-escape the quotation mark in the field name and my use of the percent sign in the field name is only to show that Chrome does not escape the percent sign itself and that there's no way to recover the data from the header sent by Chrome.

I imagine there could be a non-ASCII field name that, when encoded in some encoding, will produce something SQL-injection-like: '"; other="xx"'. That string would make the header parse into something completely different. With IE8 and FF 3.6 it looks like it would be very simple. The same applies to uploaded files names too, so it's not just a  matter of choosing sane field names.

That's all a browsers' problem though.