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

Question

我试图在HTTP服务器上实现RFC2388以支持多部分POST。

我正在查看规范，特别是内容处理的“名称”参数。

RFC 2388第3节规定：

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

我“听说”目前没有UA支持表单控件名称上的RFC2047。他们将只发送原始编码的文本。（即，如果表单控件的名称是使用UTF-8的日语，它将发送包含UTF-8日语文本的多部分POST请求）

然而，为了“忠实”，这一问题总有一天会得到解决。我宁愿坚持RFC。

但问题来自RFC 2047本身。第5（3）条规定：

• “编码字”不得出现在“地址规范”的任何部分中

冲突发生在第四个要点上。假设“name”参数是“content disposition”字段的一部分。我发现自己对规范要求我们实现者做什么感到困惑。

不管什么在“现实”中起作用/不起作用。我想问是否有人认为这也是一场冲突。

我发现自己也在问为什么RFC 2388仍然引用RFC 2047作为“名称”参数，但是仅仅几段之后就引用RFC 2231作为“文件名”参数的编码规范。鉴于RFC 2047不能用于“参数值”，这就是RFC 2231显然被创建的原因。如果RFC 2388没有被更新，以便“名称”参数使用RFC 2231。

底线是，为了实现RFC2388的功能，我是否应该或者根本不应该费心实现RFC2047？我还应该为“filename”参数使用RFC2231吗？有人知道目前任何UAs是否使用RFC 2231上传非ascii文件名吗？

Answer 1

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

描写。。。允许以不可能混淆现有消息处理软件的方式在RFC 822消息头的不同部分中编码非ASCII文本的技术。

RFC 2388并不是试图导入RFC 2047的所有假设/上下文，只是编码方法。因为这里编码的“部分”实际上是顶层“多部分/表单数据”部分的子部分，所以我认为尝试将RFC 2047中关于邮件消息头的规则应用于这些部分是没有意义的。