Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

net/http: ParseMultipartForm does not return ErrNotMultipart #6334

Closed
gopherbot opened this issue Sep 5, 2013 · 11 comments
Closed

net/http: ParseMultipartForm does not return ErrNotMultipart #6334

gopherbot opened this issue Sep 5, 2013 · 11 comments
Milestone

Comments

@gopherbot
Copy link

by Adrian.Migraso:

Before filing a bug, please check whether it has been fixed since the
latest release. Search the issue tracker and check that you're running the
latest version of Go:

Run "go version" and compare against
http://golang.org/doc/devel/release.html  If a newer version of Go exists,
install it and retry what you did to reproduce the problem.

Thanks.

What steps will reproduce the problem?
If possible, include a link to a program on play.golang.org.
1. set your header to "multipart/form-data, boundary=xxxx" (notice its a comma)
2. use ParseMultipartForm()

What is the expected output?
err should be ErrNotMultipart 


What do you see instead?
err is nil


Which compiler are you using (5g, 6g, 8g, gccgo)?
don't know, was just running go

Which operating system are you using?
windows


Which version are you using?  (run 'go version')
go1.1.2 windows/386

Please provide any additional information below.

Maybe these lines from http://golang.org/src/pkg/net/http/request.go was the cause.

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

mattrco commented Sep 9, 2013

Comment 1:

I can confirm this is still present in 18045:db5afcafd722 tip
Removing the first comparison and just returning err if not nil causes a test failure. I
can fix this, provided there isn't a reason why the comparison should stay there (and if
nobody else is currently working on it).

@mattrco
Copy link

mattrco commented Sep 9, 2013

Comment 2:

Failure on linux/amd64 with gc:
2013/09/09 22:56:13 net/http: invalid Cookie.Domain "wrong;bad.abc"; dropping domain
attribute
2013/09/09 22:56:13 net/http: invalid Cookie.Domain "bad-.abc"; dropping domain attribute
2013/09/09 22:56:13 net/http: invalid Cookie.Domain "::1"; dropping domain attribute
2013/09/09 22:56:13 net/http: invalid byte ' ' in Cookie.Value; dropping invalid bytes
2013/09/09 22:56:13 net/http: invalid byte '\x00' in Cookie.Value; dropping invalid bytes
2013/09/09 22:56:13 net/http: invalid byte '"' in Cookie.Value; dropping invalid bytes
2013/09/09 22:56:13 net/http: invalid byte ';' in Cookie.Path; dropping invalid bytes
--- FAIL: TestEmptyMultipartRequest (0.00 seconds)
    request_test.go:341: FormFile err = "request Content-Type isn't multipart/form-data", want ErrMissingFile
FAIL
FAIL    net/http    3.570s

@bradfitz
Copy link
Contributor

Comment 3:

We're past the point in the Go 1.2 release cycle where we're allowing functional
changes.  If anything, perhaps this just warrants a documentation change.  I haven't
looked into it yet.

@rsc
Copy link
Contributor

rsc commented Oct 18, 2013

Comment 5:

Labels changed: added priority-later, go1.3, removed priority-triage.

Status changed to Accepted.

@rsc
Copy link
Contributor

rsc commented Dec 4, 2013

Comment 6:

Labels changed: added release-go1.3.

@rsc
Copy link
Contributor

rsc commented Dec 4, 2013

Comment 7:

Labels changed: removed go1.3.

@rsc
Copy link
Contributor

rsc commented Dec 4, 2013

Comment 8:

Labels changed: added repo-main.

@mattrco
Copy link

mattrco commented Dec 9, 2013

Comment 9:

I took a closer look at this. With a simple server (attached), it's possible to call
ParseMultipartForm() and receive no error, and for Request.MultipartForm to be nil.
Request which results in parsed form/no error:
    curl -X POST -H 'Content-Type:multipart/form-data' -F file=mime.txt 'http://localhost:9001/upload'
Request which doesn't return an error/doesn't result in a value for
Request.MultipartForm:
    curl -X POST -H 'Content-Type:multipart/bad' -F file=mime.txt 'http://localhost:9001/upload'
The line in ParseMultipartForm which returns nil
(http://golang.org/src/pkg/net/http/request.go#L783) comes after a call to ParseForm
which has a TODO (http://golang.org/src/pkg/net/http/request.go#L704) for handling
multipart/form-data. So I'm guessing it was intended to be cleaned up.
An easy workaround is just to check the Content-Type before calling ParseMultipartForm.
Happy to submit a CL with fix and test (when the tree opens) if that's a good idea.

Attachments:

  1. main.go (429 bytes)

@mattrco
Copy link

mattrco commented Dec 18, 2013

Comment 10:

https://golang.org/cl/44040043
The server in main.go (attached above) now returns ErrNotMultipart instead of nil.

@gopherbot
Copy link
Author

Comment 11:

CL https://golang.org/cl/44040043 references this issue.

@bradfitz
Copy link
Contributor

Comment 12:

This issue was closed by revision 8d1b63a.

Status changed to Fixed.

@rsc rsc added this to the Go1.3 milestone Apr 14, 2015
@rsc rsc removed the release-go1.3 label Apr 14, 2015
@golang golang locked and limited conversation to collaborators Jun 25, 2016
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants