Boundary begins with CRLF?

[ghost]

A (.NET) server I was working with was missing the first part of my multipart (i.e. it recognized the boundary of the second section I was sending, and thought it was the first section, but missed the existence of the first section entirely), until I added a CRLF at the beginning of my boundary as in the code in this pull request.

Reading the RFC it looks like it might be required to be like that?

---

Note that the encapsulation boundary must occur at the
beginning of a line, i.e., following a CRLF, and that that
initial CRLF is considered to be part of the encapsulation
boundary rather than part of the preceding part. The
boundary must be followed immediately either by another CRLF
and the header fields for the next part, or by two CRLFs, in
which case there are no header fields for the next part (and
it is therefore assumed to be of Content-Type text/plain).

from http://www.ietf.org/rfc/rfc1341.txt

---

I thought I'd share this pull request just in case there's something to it.

[ghost]

I did some more research on this, and the most helpful article I found was http://www.stucharlton.com/blog/archives/000126.html but I'm still not clear on if I'm wrong or this .NET/IIS server I'm talking to is wrong.

Stu there did some informal tests and found inconsistent results in implementations:

---

Yikes. I've sent an email feedback to the WS-I organization indicating that this seems to be a misstatement.
Informal testing (ymmv) indicates spotty compliance of how many CRLFs are between the last HTTP header and the first MIME boundary:

Application Server A inserts 2 CR/LF, expects at least 2
Application Server B inserts 3 CR/LFs, expects at least 2
Application Server C inserts 2 CR/LFs, expects at least 2
Web Services Library A inserts 3 CR/LFs, expects at least 2
Web Services Library B inserts 2 CR/LFs, expects at least 2
XML Appliance inserts 3 CR/LFs, requires at least 3

---

[ghost]

Re-reading the spec for the 15th time, I'm more sure that "3 CR/LFs" between the last http header and the first mime boundary is "correct". I made changes to the pull request herein to only add one extra cr/lf there, and updated the tests to match ... I'm up for comments/discussion on how I'm wrong too though :)

The [...that initial CRLF is considered to be part of the encapsulation boundary rather than part of the preceding part.] seems to be the key part that causes the confusion in implementations. My current understanding is that the first 2 CR/LFs are for other purposes, but then another CR/LF is required as "part of the encapsulation boundary" because the first 2 didn't count.

[mikeal]

the number of options we need to support peoples varied HTTP implementations is getting out of control. i hate the world :)