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

Question

我们multipart/form-data 来自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随机生成边界,但让我们假设"百万只猴子进入百万网络表单"场景.

有没有一种标准的方法来处理这种不可能但仍然可能的情况？

应该text/plain(或者甚至可能像image/jpeg或application/octet-stream)是"编码"或部分内以某种方式"逃"的信息？

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

Answer 1

HTTP委托MIME RFC来定义multipart/这里的类型.规则在RFC 2046第5.1节中列出.

RFC只是声明边界不得出现:

边界定界符不得出现在任何封装部分内,单独一行或作为任何行的前缀.这意味着组成代理能够选择并指定不包含封闭多部分的边界参数值作为前缀的唯一边界参数值是至关重要的.

和

注意:由于边界分隔符不得出现在要封装的正文部分中,因此用户代理必须谨慎选择唯一的边界参数值.上述示例中的边界参数值可能是设计用于生成边界定界符的算法的结果,该边界定界符具有非常低的已经存在于要封装的数据中的概率,而不必预扫描数据.对于具有旧用户代理的接收者,替代算法可能导致更"可读"的边界分隔符,但需要更多关注边界定界符可能出现在封装部分中某行的开头的可能性.最简单的边界定界线可能是"---",其边界定界线为"-----".

大多数MIME软件只是生成一个随机边界,这样在边界中出现边界的概率在统计上是不可能的 ; 例如,碰撞可能发生,但发生这种情况的可能性很低,以至于不可行.计算机UUID值依赖于相同的原则; 如果你在一年内产生几万亿UUID,产生两个相同UUID值的概率与被陨石击中的人大致相同,两者都有170亿的机会.

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

因此,处理这种可能性的标准方法是简单地使可能性几乎不可能.如果您有更大的机会存储电子邮件被陨石击中,为什么要担心MIME边界？