-
Notifications
You must be signed in to change notification settings - Fork 17.5k
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: add FileContentDisposition #46771
Comments
For the record, the new API proposed in https://golang.org/cl/153178 is // CreateFormFileWithContentType is a convenience wrapper around CreatePart.
// It creates a new form-data header with the provided field name, file name and content type.
func (w *Writer) CreateFormFileWithContentType(fieldname, filename, contentType string) (io.Writer, error) |
What if instead we add:
? Then CreateFormFile is very simple:
and at that point if you want a custom Content-Type or any other header, it's reasonable to just write your own version. |
This proposal has been added to the active column of the proposals project |
The latter would work, but it still would require 4 lines of code (excluding any function declaration) just to use a different content type. And I think that form files mostly come in just one variant - what the existing With your proposal, for most file uploads you'd make developers write this:
instead of this:
Perhaps |
This is an unusual enough case that it's OK to have to write 4 lines. The important part is not having to copy-paste the complex Sprintf. Retitled to be about the FileContentDisposition function. |
I have to disagree with you that a content type that is not |
I only said it was OK to write 4 lines for that case. The part that is bad to copy-paste is the Sprintf call, hence the function. |
Based on the discussion above, this proposal seems like a likely accept. |
Copying a possible alternative from #49329:
This pushes the header name (in addition to the value) into the |
As soon as there's a second field to write a helper for, having helpers that make the map is not going to scale. It seems like we should probably stick with the field-specific helper. |
No change in consensus, so accepted. 🎉 |
Change https://go.dev/cl/531995 mentions this issue: |
For uploading files as part of multipart/form-data requests, the specification allows the content type to be specified, e.g. application/pdf. However, the current version of Go always uses application/octet-stream. While it's possible to work around this, it requires duplicating code like the
Sprintf
command and the escaping. An example can be found at for example, see https://github.com/Ingenico-ePayments/connect-sdk-go/blob/master/defaultimpl/DefaultConnection.go#L345. Lines 345-348 could all be replaced by a single line if the Go API supported custom content types, and the escaping of quotes could be removed completely.I've already created a PR for this which: #29140. It's fully backward compatible because it introduces a new function; the existing function delegates to the new one.
The text was updated successfully, but these errors were encountered: