I'm trying to implement RFC 2388 on a HTTP server to support multipart POST.
I am looking at the specification specifically at the content-disposition's "name" parameter.
Under section 3 of RFC 2388 it states:
Field names originally in non-ASCII character sets may be encoded within the value of the "name" parameter using the standard method described in RFC 2047.
I have 'heard' that no UA currently support RFC2047 on form control names. They will simply send the text in it's original encoding. (i.e. if the form control's name is in Japanese using UTF-8 it'll send the multipart POST request with the Japanese text in UTF-8)
However, in the interest of being 'faithful' that this'll one day get resolved. I prefer sticking to the RFC.
The problem though, comes from RFC 2047 itself. Under section 5(3) Which states:
- An 'encoded-word' MUST NOT appear in any portion of an 'addr-spec'.
- An 'encoded-word' MUST NOT appear within a 'quoted-string'.
- An 'encoded-word' MUST NOT be used in a Received header field.
- An 'encoded-word' MUST NOT be used in parameter of a MIME Content-Type or Content-Disposition field, or in any structured field body except within a 'comment' or 'phrase'.
The conflict is on the 4th bullet point. Given that the 'name' parameter is part of the "content-disposition" field. I find myself lost as to what the specification wants us implementors to do.
Regardless of what works/doesn't work in 'reality'. I want to ask whether anybody find this a conflict as well.
I find myself asking also why is RFC 2388 still referring to RFC 2047 for the "name" parameter but just a couple of paragraphs later then refer to RFC 2231 as the encoding specification for "filename" parameter. Given that RFC 2047 cannot be used for "parameter values" which is why RFC 2231 was apparently created. Should RFC 2388 not have been updated as well so that the "name" parameter utilise RFC 2231.
The bottom line is, should I, or should I not bother with implementing RFC 2047 AT ALL for the purpose of fulfiling it's functions for RFC 2388? And should I also even bother with RFC 2231 for the 'filename' parameter? Does anybody know whether RFC 2231 is currently used by any UAs to upload non-ascii filenames?
I don't really see this as a conflict. Note that RFC 2047
describes...techniques to allow the encoding of non-ASCII text in various portions of a RFC 822 message header, in a manner which is unlikely to confuse existing message handling software.
RFC 2388 is not trying to import all the assumptions/context of RFC 2047, merely the method of encoding. Because the "parts" being encoded here are actually children of the top-level "multipart/form-data" part, I don't think it makes sense to try and apply the rules of RFC 2047 regarding mail message headers to these parts.
来源：https://stackoverflow.com/questions/13649258/server-implementation-of-rfc-2388-multipart-post-conflict-with-rfc-2047