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?

Community
  • 1
  • 1
eckes
  • 64,417
  • 29
  • 168
  • 201
  • SubValue *(parameters)* order is irrelevant. You break by `;` and split by `=` to get SubValues of Headers. Then you just refer to the `'boundary'` value and `'charset'` values... regardless of their order. – CodeAngry Mar 14 '15 at 17:25

2 Answers2

2

You need to parse the whole header field according to the grammar for media types; "charset" is a parameter just like "boundary".

Julian Reschke
  • 40,156
  • 8
  • 95
  • 98
1

I can't comment on your question specifically about IE10's behaviour, but I will comment on your question about what you should do about it:

shall the trailing data be ignored or shall I (as spec compliant HTTP server) drop the request and send an error to the client?

If IE10 behaves as you describe, and your server sends an error in response to that, then it means you're basically going to be sending error responses all the time to IE10 users.

IE10 users won't be able to do anything about the error, so this in turn means you're going to in effect completely lock those users out from whatever service your server is providing.

At times like this, it's worth considering Postel's law: Be conservative in what you send, be liberal in what you accept.

So I would urge you not to send an error, even if the behaviour isn't strictly according to the spec. If you can handle it without an error, then that is the best option.

Spudley
  • 166,037
  • 39
  • 233
  • 307
  • :-) I surely don't want to block all IE10 users. The core of the question is whether the behavior of IE is ok (I will silently accept the request) or not (I'll do lots of rant against IE). – eckes Nov 04 '13 at 15:34