RFC 2388多部分POST的服务器实现与RFC 2047冲突？ [英] Server implementation of RFC 2388 multipart POST conflict with RFC 2047?

问题描述

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

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.

根据RFC 2388的第3部分，它声明：

Under section 3 of RFC 2388 it states:

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

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.

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

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)

但是，在这种有一天能得到解决的兴趣是忠诚。我更喜欢坚持使用RFC。

However, in the interest of being 'faithful' that this'll one day get resolved. I prefer sticking to the RFC.

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

The problem though, comes from RFC 2047 itself. Under section 5(3) Which states:

• 编码字不得出现在任何部分一个'addr-spec'。


• 一个'encoded-word'绝不能出现在'quoted-string'中。


• 一个'编码' -word'不得在收到的标题字段中使用。


• 不得在MIME
  内容类型或内容处置的参数中使用'encoded-word'字段，或任何结构化的
  字段正文，但在评论或词组中除外。

• 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'.

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

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.

我发现自己也在问为什么RFC 2388仍然将RFC 2047称为name参数，而只是之后的几段然后将RFC 2231称为filename参数的编码规范。鉴于RFC 2047不能用于参数值，这就是显然创建RFC 2231的原因。 RFC 2388也不应该更新，以便name参数使用RFC 2231。

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.

底线是，我应该还是不应该为执行而烦恼RFC 2047 AT ALL是为了实现RFC 2388的功能吗？我是否还应该使用RFC 2231来处理'filename'参数？有没有人知道任何UAs目前是否使用RFC 2231来上传非ascii文件名？

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?

推荐答案

我真的没看到这是一场冲突。请注意，RFC 2047

I don't really see this as a conflict. Note that RFC 2047

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

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未尝试导入RFC 2047的所有假设/上下文，仅仅是编码方法。因为这里编码的部分实际上是顶级multipart / form-data部分的子代，所以我认为尝试将RFC 2047的规则应用于这些部分的邮件消息头是不合理的。

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.

这篇关于RFC 2388多部分POST的服务器实现与RFC 2047冲突？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！