Why?

The motivation for https://golang.org/pkg/net/http/#Request.MultipartReader was so you could get file uploads from browsers easily.

What uses multipart/mixed?

And what's wrong with your "good" handler? That seems fine to me. That is, our underlying https://golang.org/pkg/mime/multipart/#Reader already supports what you want. You just don't like the convenience wrapper, but it's not clear why it's convenient.

It's also not clear that this is safe to do. Isn't multipart/mixed used when people are sending "alternatives"? I'd be a little concerned that code that previously was unprepared for such forms would now blindly accept it, without considering which alternative they want.

I'd prefer people to "opt-in" to the expanded set of allowed inputs by calling the underlying Reader constructor themselves.

@bradfitz my current use case is uploading a file + json metadata in one request rather than:

1. POST req 1 (json), get an id, post req 2 (file) and use the id from req 1.
2. Convert the file to base64 (33% size increase) and include it in the json request.

multipart/mixed is pretty much the same as multipart/form-data except each "part" can have different headers / content-type and it's generally used in SMTP, however few APIs use it here and there.

https://golang.org/pkg/net/http/#Request.MultipartReader already supports multipart/form-data, the underlying https://golang.org/pkg/mime/multipart/#Reader supports multipart/* in general.

edit you were thinking about multipart/alterntive not multipart/mixed.

Sure, we can accept multipart/mixed too.

Change https://golang.org/cl/95975 mentions this issue: net/http: support multipart/mixed in Request.MultipartReader()