cc @neild @minux

CreateFormFile is a convenience wrapper, but it does seem like a gap in the package API that there's no function that sets the Content-Disposition field correctly while allowing the caller to specify the Content-Type.

Perhaps a ("mime/multipart".Writer).CreateFormFileWithContentType(fieldname, filename, contentType string) would be a reasonable addition. If someone wants to pursue adding this, the new function will need to follow the proposal process.

@neild ok, so what are my next steps to make a proposal?

@x1unix See https://golang.org/s/proposal.

@ianlancetaylor @neild

A non-proposal issue can be turned into a proposal by simply adding the proposal label

I added a proposal prefix to the issue, this should be legit according to the docs.
Do I need any additional steps to do?

Do I need any additional steps to do?

No.

Concretizing the proposal:

package multipart

// CreateFormFileWithContentType is a convenience wrapper around CreatePart.
// It creates a new form-data header with the provided field name and file name.
func (w *Writer) CreateFormFileWithContentType(fieldname, filename, contentType string) (io.Writer, error) {}

@neild what do you think about options pattern for this method?

Just to add additional third argument with options like this:

type Option = func(h *textproto.MIMEHeader)

var WithContentType Option = ...
var WithContentRanges Option = ...

func (w *Writer) CreateFormFile(fieldname, filename string, options ...Option) (io.Writer, error)

This allows to set additional headers like Content-Ranges for partial upload, or other headers.
Also the method will be backward compatible.

@neild what do you think about options pattern for this method?

Seems heavyweight for this case.

If we want a more general-purpose helper function, then perhaps something like this would be useful:

// NewFormDataHeader creates a form-data header with the provided field name.
func NewFormHeader(fieldname, filename string) textproto.MIMEHeader {
  h := make(textproto.MIMEHeader)
  if filename == "" {
    h.Set("Content-Disposition", fmt.Sprintf(`form-data; name="%s"`, escapeQuotes(fieldname)))
  } else {
    h.Set("Content-Disposition", fmt.Sprintf(`form-data; name="%s"; filename="%s"`, escapeQuotes(fieldname), escapeQuotes(filename)))
  }
}

Usage:

h := multipart.NewFormHeader("field", "")
h.Set("Content-Rodent", "gopher")
wr, err := w.CreatePart(h)

@neild seems reasonable. Interesting also to hear other opinions.

This looks like a duplicate of #46771 ?

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

This looks like a duplicate of #46771 ?

@rsc looks like that this issue rather complements #46771. Original issue is about content disposition and this one is about content type header, but the solution should resolve both issues.

With #46771 accepted, this use case becomes:

h := make(textproto.MIMEHeader)
h.Set("Content-Disposition", FileContentDisposition(fieldname, filename)
h.Set("Content-Type", "application/pdf")
p, err := w.CreatePart(h)

Does that seem OK? It seems clearer and more extensible to do that than to have another constructor for each header we might want to set.

@rsc looks good to me. What do you think about idea to introduce constants for formdata-common headers like Content-Type, Content-Disposition, etc?

h := make(textproto.MIMEHeader)
h.Set(multipartHeader.ContentDisposition, FileContentDisposition(fieldname, filename)
h.Set(multipart.HeaderContentType, "application/pdf")
p, err := w.CreatePart(h)

We have avoided adding "Content-Type" as a named constant in net/http, so it doesn't seem like we should add it here either. We did reluctantly add things like http.MethodGet, but now we get many CLs changing "GET" to http.MethodGet, which is churn that makes the code harder to read. I don't think we want to go down that road again.

Given that #46771 takes care of this use case, closing as duplicate.

This proposal is a duplicate of a previously discussed proposal, as noted above,
and there is no significant new information to justify reopening the discussion.
The issue has therefore been declined as a duplicate.
— rsc for the proposal review group