This was fixed in Go 1.5.2: https://golang.org/doc/devel/release.html#go1.5.minor

(or at least, an identical-sounding bug was fixed. If you still see it with Go 1.5.2 or Go 1.5.3, let us know)

Thanks! I'll retest it w/ go 1.5.3

@bradfitz upgrading from 1.5.1 to 1.5.3 didn't change the outcome of the unit test -- the go multipart module still can't correctly parse that particular multipart request.

It might be caused by some subtlety about the way the original ObjectiveC-based client is sending the request, because in a second unit test I tried using a go http client to reproduce the issue by sending a multipart/related request with approximately the same content, and couldn't reproduce any issues in either go 1.5.1 or 1.5.3.

By "approximately the same content", I mean:

• The json part wasn't gzipped as it was in the original problematic request
• The boundary was different, -9PWGbT-1_r1QpgvW0I-4E3 in failing vs 1174c809f7f3b164d57df5f5f23c652994408f51d135352b26e26a96ff6e in passing
• The image attachment parts were identical and in the same order

@adg, you have time to look at this? You'll be working a bit before me, otherwise I can look (my) Monday.

@bradfitz @adg I managed to reproduce it via the go http client in a third unit test -- the only difference from the second unit test is that it explicitly sets the boundary string to -9PWGbT-1_r1QpgvW0I-4E3 in the client side mulitpart writer.

Test output

@tleyden, this bug report is already way above normal quality-wise, but if I could be greedy: can you whittle it down to a single file with no external data dependencies, suitable for writing a TestFoo(t *testing.T) function out of? Or even something that would work in play.golang.org? That's 95% of the work of fixing bugs, usually, writing a reproducible small test case.

Yeah np, I'll give it a shot and post to the issue if I can come up with something.

OK I managed to remove the external file dependencies and replaced them with zero'd out byte slices, and it's still reproducing the issue. Admittedly it's still a bit clunky since it starts an http listener and goes through a client round trip.

• TestReadMultipartBody4
• Test output

@tleyden I tried running your TestReadMultipartBody4 against Go commit 801bebe and the test passed correctly. What version are you testing against?

=== RUN   TestReadMultipartBody4
2016/01/25 14:45:48 Writer using boundary: -9PWGbT-1_r1QpgvW0I-4E3
2016/01/25 14:45:48 attrs: map[boundary:-9PWGbT-1_r1QpgvW0I-4E3]
2016/01/25 14:45:48 Part: &{map[Content-Type:[application/json]] 0xc8200c82a0 0xc820948180 0  map[] {0xc8209a81e0}}
2016/01/25 14:45:48 Part data length: 2
2016/01/25 14:45:48 Part: &{map[Content-Disposition:[attachment; filename="result_image".]] 0xc8200f4070 0xc820948180 0  map[] {0xc820010230}}
2016/01/25 14:45:48 Part data length: 68881
2016/01/25 14:45:48 Part: &{map[Content-Disposition:[attachment; filename="source_image".]] 0xc8200f40e0 0xc820948180 0  map[] {0xc8200102d0}}
2016/01/25 14:45:48 Part data length: 97655
2016/01/25 14:45:48 Part: &{map[Content-Disposition:[attachment; filename="style_image".]] 0xc8200f4150 0xc820948180 0  map[] {0xc8200105f0}}
2016/01/25 14:45:48 Part data length: 85053
2016/01/25 14:45:48 err getting nextpart: EOF
2016/01/25 14:45:48 response status code: 200
--- PASS: TestReadMultipartBody4 (0.00s)

I'm on go 1.5.3 on OSX:

$ go version
go version go1.5.3 darwin/amd64

I downloaded it from here and built it from source using make.bash on top of my previous go version (1.5.1)

I'm able to reproduce the issue at go1.5.3, but the test passes against HEAD (~go1.6).

The question is whether it is worth fixing and releasing Go 1.5.4, or whether we should just recommend upgrading to go1.6, which should be out in a couple of weeks.

I don't remember fixes to this code this cycle. Did you narrow down which commit is responsible?

I'll try bisecting.

Looks like the fix happened in commit 821b549

Since this is fixed at HEAD, and Go 1.6 will be released soon, I'll close this issue.

Works for me. Thanks for getting to the bottom of this!