forms - 如果表单数据边界包含在附件中怎么办？

Question

让我们以下面的multipart/form-data为例taken from w3.com :

Content-Type: multipart/form-data; boundary=AaB03x

--AaB03x
Content-Disposition: form-data; name="submit-name"

Larry
--AaB03x
Content-Disposition: form-data; name="files"; filename="file1.txt"
Content-Type: text/plain

... contents of file1.txt ...
--AaB03x--

它非常简单，但假设您正在编写代码来实现它并从头开始创建这样的请求。假设 file1.txt 是由用户创建的，我们无法控制其内容。

如果文本文件 file1.txt 包含字符串 --AaB03x 怎么办？ 您可能生成了边界 AaB03x 随机，但让我们假设一个 "million monkeys entering a million web forms"场景。

是否有标准方法来处理这种不太可能但仍有可能发生的情况？

text/plain(甚至可能是 image/jpeg 或 application/octet-stream)是否应该“编码”还是以某种方式“转义”中的某些信息？

或者开发人员是否应该始终在文件的内容中搜索边界，然后反复不断地选择一个新的随机生成的边界，直到在文件中找不到所选的字符串？

Answer 1

HTTP 委托(delegate) MIME RFC 在这里定义 multipart/ 类型。规则在 RFC 2046 section 5.1 中列出。 .

RFC 简单地声明边界不得出现:

The boundarydelimiter MUST NOT appear inside any of the encapsulated parts, on aline by itself or as the prefix of any line. This implies that it iscrucial that the composing agent be able to choose and specify aunique boundary parameter value that does not contain the boundaryparameter value of an enclosing multipart as a prefix.

和

NOTE: Because boundary delimiters must not appear in the body partsbeing encapsulated, a user agent must exercise care to choose aunique boundary parameter value. The boundary parameter value in theexample above could have been the result of an algorithm designed toproduce boundary delimiters with a very low probability of alreadyexisting in the data to be encapsulated without having to prescan thedata. Alternate algorithms might result in more "readable" boundarydelimiters for a recipient with an old user agent, but would requiremore attention to the possibility that the boundary delimiter mightappear at the beginning of some line in the encapsulated part. Thesimplest boundary delimiter line possible is something like "---",with a closing boundary delimiter line of "-----".

大多数 MIME 软件只是简单地生成一个随机边界，使得该边界出现在部分中的概率在统计上不太可能；例如可能会发生碰撞，但发生这种情况的可能性非常低，以至于不可行。电脑UUID values依赖相同的原则；如果一年生成几万亿个 UUID，则生成两个相同 UUID 值的概率与某人被陨石击中的概率大致相同，两者的概率均为 170 亿分之一。

请注意，您通常将二进制数据编码为某种形式的 ASCII 安全编码，例如 base64，这是一种不包含破折号的编码，消除了二进制数据包含边界的可能性。

因此，处理可能性的标准方法是简单地使可能性变得几乎不可能。如果存储电子邮件的计算机更有可能被陨石击中，为什么还要担心 MIME 边界？