RFC 2388多部分POST的服务器实现与RFC 2047冲突？

Question

我正在尝试在HTTP服务器上实现RFC 2388以支持多部分POST.

我正在专门针对content-disposition的"name"参数查看规范.

根据RFC 2388第3节,它规定:

最初在非ASCII字符集中的字段名称可以使用RFC 2047中描述的标准方法在"name"参数的值内编码.

我'听说'UA目前在表单控件名称上不支持RFC2047.他们只需以原始编码发送文本.(即如果表单控件的名称是使用UTF-8的日语,它将发送带有UTF-8的日文文本的多部分POST请求)

但是,为了"忠实",这有一天会得到解决.我更喜欢坚持使用RFC.

但问题来自RFC 2047本身.根据第5(3)条规定:

• '编码字'不得出现在'addr-spec'的任何部分.
• "编码字"绝不能出现在"引用字符串"中.
• "编码字"不得在"已接收"标题字段中使用.
• "编码字"不得用于MIME内容类型或内容处置字段的参数,也不得用于"评论"或"短语"中的任何结构化字段正文中.

冲突发生在第4点.鉴于'name'参数是"content-disposition"字段的一部分.我发现自己迷失了规范要求我们实现者做什么.

无论什么在"现实"中起作用/不起作用.我想问一下是否有人发现这也是冲突.

我发现自己也在问为什么RFC 2388仍然将RFC 2047称为"name"参数,但稍后只有几段后面将RFC 2231称为"filename"参数的编码规范.鉴于RFC 2047不能用于"参数值",这就是显然创建RFC 2231的原因.RFC 2388是否也没有更新,因此"name"参数使用RFC 2231.

最重要的是,我应该或者不应该为实现RFC 2388的功能而实施RFC 2047 AT ALL而烦恼吗？我是否还应该为RFC 2231打扰'filename'参数？有人知道任何UA目前是否使用RFC 2231来上传非ascii文件名？

Answer 1

我真的不认为这是一个冲突。请注意 RFC 2047

描述...允许在RFC 822 消息头的各个部分中对非 ASCII 文本进行编码的技术，其方式不太可能混淆现有的消息处理软件。

RFC 2388 并不试图导入 RFC 2047 的所有假设/上下文，而只是导入编码方法。因为此处编码的“部分”实际上是顶级“multipart/form-data”部分的子级，所以我认为尝试将有关邮件消息标头的 RFC 2047 规则应用于这些部分是没有意义的。