当ErrNotMultipart时ParseMultipartForm（）返回nil

Question

http://golang.org/src/pkg/net/http/request.go

Why it returns to nil when ErrNotMultipart?

mr, err := r.multipartReader()
767     if err == ErrNotMultipart {
768         return nil 
769     } else if err != nil {
770         return err
771     }

In my case, I had a typo from my header

multipart/form-data, boundary=xxxx

The above should have a semi-colon instead of a comma. Now, I was tracing this for hours, because I thought ParseMultipartForm processed the data successfully.

There could be a strong reason why it was forced to nil, judging from the code.

(I posted this same question at golang-nuts group, but when I posted a reply to the first collaborator, my reply was not posted successfully. So, I think stackoverflow is a better tool for posting this question)

Answer 1

I think you did it right in the first place to write to golang-nuts instead of here.

This does indeed look like a bug and should therefore be discussed in the issue tracker or on golang nuts. Note that golang-nuts is moderated and therefore your posts will not appear immediately (which might have happened to you).

As a workaround you can use Request.MultipartReader and do the reading by yourself (copied from ParseMultipartForm):

mr, err := r.multipartReader() // don't forget to handle err
f, err := mr.ReadForm(maxMemory) // don't forget to handle err

for k, v := range f.Value {
    r.Form[k] = append(r.Form[k], v...)
}
r.MultipartForm = f

Judging from what I can deduce from the code history, this was simply overlooked. The changes are from 2011 and the review for the particular lines of code can be found here. The tests don't seem to cover this particular parse error. The review even says:

On 2011/04/28 00:08:40, bradfitz wrote: I think you'll always return an error here for multipart forms. See comment above.

Fixed.

Which was done for almost all errors but this one. So, as I said, I think it is a bug.