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).
I thought I'd share this pull request just in case there's something to it.
Adding a line break to the preamble as the first part of a multipart …
…was not recognized by a server I was communicating with.
Merge remote-tracking branch 'upstream/master'
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
Merge branch 'master' of https://github.com/mikeal/request
Updating with corresponding tests.
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.
Removing console.log of multipart
Okay, trying it as an optional parameter, with a new test in test-bod…
…y.js to verify
the number of options we need to support peoples varied HTTP implementations is getting out of control. i hate the world :)