mime/multipart: problem parsing for certain attachment lengths

[fclaude]

The problem seems to arise when we include a file (as the last element of a multipart-form) whose length makes the final peeking buffer finish with --DELIMITER- (for example, a file with 4031 A's).

I've tried this using go1.5, go1.5.1 and devel. It should affect all architectures.

I've located the problem in function func (mr *Reader) peekBufferSeparatorIndex(peek []byte) (idx int, isEnd bool). This function does the following check:

if len(peek) > 1 && peek[0] == '-' && peek[1] == '-' {
    return idx, true
}
peek = skipLWSPChar(peek)
// Don't have a complete line after the peek.
if bytes.IndexByte(peek, '\n') == -1 {
    return -1, false
}

For the input mentioned, the function returns -1 and ends up consuming the first dash of the delimiter string when reading the content of the file. I've tried a fix for this adding the following condition:

if len(peek) == 0 || len(peek) == 1 && peek[0] == '-' {
    return idx, false
}
if len(peek) > 1 && peek[0] == '-' && peek[1] == '-' {
    return idx, true
}
peek = skipLWSPChar(peek)
// Don't have a complete line after the peek.
if bytes.IndexByte(peek, '\n') == -1 {
    return -1, false
}

With the change the problem doesn't arise anymore and all tests included in the mime/multipart package pass. I'll work on a CL for this fix.

Best Regards,
Francisco Claude.

[gopherbot]

CL https://golang.org/cl/14652 mentions this issue.

[bradfitz]

Flagging this as a potential Go 1.5.2 candidate, since (as noted at perkeep/perkeep#642 (comment)) there's no workaround short of forking all of net/http and mime/multipart, and even then your dependencies may use the unforked version of net/http.

And the fix is tiny.

/cc @adg @mpl

[rsc]

OK for Go 1.5.2

[gopherbot]

CL https://golang.org/cl/16969 mentions this issue.