defnull
Newlines, quotes and backslashes in field names or filenames not decoded correctly.
The HTML5 specification defines that "field names and filenames for file fields [...] must be escaped by replacing any 0x0A (LF) bytes with the byte sequence %0A, 0x0D (CR) with %0D and 0x22 (") with %22. The user agent must not perform any other escapes." and tests show that modern browsers actually do that. The traditional header quoting (which involves backslash-escaping quotes and backslashes) is NOT applied. The string is (always?) quoted, but since it cannot contain quotes that need backslash-escaping, backslashes are left alone and not doubled.
This means that Multipart currently decodes field names or filenames incorrectly if they contain ", \r, \n or two backslashes in a row. The first three characters are percent-encoded by browsers but not percent-decoded by multipart, and two backslashes in a row are not escaped (doubled) by browsers but multipart un-escapes them.
For the record: other control characters (e.g. null bytes) are encoded as \xef\xbf\xbd, which is the UTF8 sequence for the unicode "Replacement character". Good to know.
Interestingly, this is not full percent-encoding as mentioned (but not required or suggested) by RFC-7578. Only three specific characters are percent-encoded, other non-ASCII characters are fair game and encoded as UTF8. There may be other clients that do full percent-encoding, but since we cannot know that for sure, and such a behavior would be a-typical for browsers, it's probably best to not touch those. Implementing the correct behavior in multipart would not destroy any information in those full-percent-encoded strings, though. Applications that know they have to deal with outdated clients would still be able to decode those strings.
The impact of this bug is probably very low. Field names or filenames containing newlines or backslashes should be extremely rare and quotes are also very uncommon. But we aim to fully support whatever browsers may send, and that's part of the deal.
