Reputation: 991
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)
Upvotes: 2
Views: 1281
Reputation: 57649
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.
Upvotes: 3