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
mime/multipart: "filename" Content-Disposition parameter should be optional #19183
Comments
@matiasanaya if interested, please feel free to send a CL and we'll review it. |
@odeke-em perfect, I'll work on it. |
How can we know if there is a file present? Is it enough to know that there is a Content-type header in the Part? I cannot see any other way of differentiating values from files in a multipart form. Please enlighten me if I am mistaking. |
Change https://golang.org/cl/70931 mentions this issue: |
I don't understand how you can expect to use |
I am not sure I understand your comment @ianlancetaylor , patch only changes the behaviour when a filename is not specified. From what I can see, the With the change, all |
Is that true? The original code tests |
Thanks, I was thinking about this just before I went to sleep yesterday, but forgot to add it. I will revise the change. |
Change https://golang.org/cl/121055 mentions this issue: |
Change https://golang.org/cl/121075 mentions this issue: |
…name Revert the code changes of CL 96975 and CL 70931, but keep the tests, appropriately modified for the code changes. This restores the 1.9 handling of form-data entries with missing or empty file names. Changing the handling of this simply confused existing programs for no useful benefit. Go back to the old behavior. Updates #19183 Fixes #24041 Change-Id: I4ebc32433911e6360b9fd79d8f63a6d884822e0e Reviewed-on: https://go-review.googlesource.com/121055 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
…ng/empty form-data file name Revert the code change of CL 70931, but keep the test, appropriately modified for the code changes. Also add a new test. This restores the 1.9 handling of form-data entries with missing or empty file names. Changing the handling of this simply confused existing programs for no useful benefit. Go back to the old behavior. Updates #19183 Fixes #24041 Change-Id: Ie7a0309a061218ceda3bbc2a7da85e6fb3dd016d Reviewed-on: https://go-review.googlesource.com/121075 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
What version of Go are you using?
go version go1.7.4 darwin/amd64
What operating system and processor architecture are you using?
What did you do?
Tried to read a "file" in a
multipart/form-data
which did not have afilename
.What did you expect to see?
multipart.File
andmultipart.FileHeader
being correctly built and returned.What did you see instead?
Error:
http: no such file
Thoughts?
multipart ReadForm assumes a "filename" will be present. RFC2388 mentions that this parameter is optional.
Looks like
multipart.Form
(which has amultipart.Form.Value
and amultipart.Form.File
map) tries to figure out what's a "file" and what's a "value" at parse time without caller input. Is this a decision that can be revisited?Also wouldn't it be more correct to have a
multipart.Form.Part
abstraction which can be used as a "Value" (string
) or a "File" (*FileHeader
)?The text was updated successfully, but these errors were encountered: