2

I've got a wireshark capture of a POST request sent by IE10. The POST request is issued as specified by RFC 1867 and it includes a boundary:

Content-Type: multipart/form-data; boundary=945637143527273; charset=UTF-8

What strikes me rather odd is the

charset=UTF-8

part after the token

boundary=945637143527273;

When I look at the Examples section in the RFC, the Content-Type header is always terminated by the boundary and there is no trailing data such as a charset.

So, was there some addon to the spec allowing such a behavior, shall the trailing data be ignored or shall I (as spec compliant HTTP server) drop the request and send an error to the client?

Edit: further investigation for that topic lead me to this question:

What rules apply to MIME boundary?

The accepted answer refers to RFC 2046 where the boundary gets specified as follows:

boundary := 0*69<bchars> bcharsnospace

bchars := bcharsnospace / " "

bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" /

                  "+" / "_" / "," / "-" / "." /
                  "/" / ":" / "=" / "?"

So, since bcharsnospace does not contain a ; the charset=UTF-8 part clearly does not belong to the boundary. Shall I ignore it in that case or is this an invalid value for the Content-Type header?

4

2 回答 2

2

您需要根据媒体类型的语法解析整个头部字段；“charset”是一个参数，就像“boundary”一样。

于 2013-11-04T15:29:30.893 回答
1

我无法具体评论您关于 IE10 行为的问题，但我会评论您应该如何处理的问题：

应该忽略尾随数据还是应该（作为符合规范的 HTTP 服务器）放弃请求并向客户端发送错误？

如果 IE10 的行为与您描述的一样，并且您的服务器会发送一个错误响应，那么这意味着您基本上将一直向 IE10 用户发送错误响应。

IE10 用户将无法对错误采取任何措施，因此这反过来意味着您将实际上将这些用户完全锁定在服务器提供的任何服务之外。

在这种情况下，值得考虑一下 Postel 定律：发送的内容要保守，接受的内容要自由。

因此，我敦促您不要发送错误，即使行为不严格符合规范。如果您可以毫无错误地处理它，那么这是最好的选择。

于 2013-11-04T15:24:14.023 回答