Add MediaType.FORM_DATA

[GoogleCodeExporter]

Please, add media type for multipart/form-data MIME type.

Original issue reported on code.google.com by Ash2kk@gmail.com on 21 Oct 2013 at 10:25

[GoogleCodeExporter]

Hm, constant with that name already exists, but it has 
application/x-www-form-urlencoded value. Probably name should be something 
different for newly added constant.

Original comment by Ash2kk@gmail.com on 21 Oct 2013 at 10:28

[GoogleCodeExporter]

This came up recently internally, and the issue with it was that multipart 
media types require a boundary parameter according to RFC 2046.

Original comment by cgdecker@google.com on 21 Oct 2013 at 1:55

[GoogleCodeExporter]

To elaborate a bit, the feature was requested so that somebody could use the 
constant in conjunction with is().  The issue, as cgdecker@ mentions, is that 
multipart/form-data isn't a valid media type by itself because it always 
requires the boundary parameter.  So, while the constant might make sense for 
matching, it would be bug-prone for serving content.  The suggested solution 
for matching in the meantime was to just make a one-off helper that checks the 
type and subtype specifically. 

Given all of that background, can you elaborate on what you were hoping to use 
it for?

Original comment by gak@google.com on 21 Oct 2013 at 4:36

[GoogleCodeExporter]

(Aside: Is the ambiguity of "FORM_DATA" potentially confusing enough that we 
should rename it to "FORM_URLENCODED" or something?)

Original comment by cpov...@google.com on 21 Oct 2013 at 4:40

[GoogleCodeExporter]

I think this may be something that's been discussed before, but a separate type 
for matching media types vs. representing a complete media type seems like it 
might be useful. The wildcard MediaType constants feel kind of out of place to 
me.

Original comment by cgdecker@google.com on 21 Oct 2013 at 5:07

[GoogleCodeExporter]

I was hoping to use it for matching using is() in my code that extracts 
boundary from request. For now I created a constant using .create() method for 
that purpose.

p.s. from my point of view FORM_URLENCODED is better than FORM_DATA.

Original comment by Ash2kk@gmail.com on 22 Oct 2013 at 3:27

[GoogleCodeExporter]

Also we use multipart/form-data as response type - in some cases it is 
convenient to provide multipart response. So multipart/form-data can be used 
WITHOUT boundary to specify HTTP Accept header, sent from client (that's what 
we do).

Original comment by Ash2kk@gmail.com on 22 Oct 2013 at 7:48

[GoogleCodeExporter]

Yeah, that's a subtle distinction: multipart/form-data is a valid media 
_range_, but not a valid media type.  At one point I started the work of making 
MediaRange a proper type and this does seem like a good argument for finishing 
that up.

Original comment by gak@google.com on 22 Oct 2013 at 5:47

[GoogleCodeExporter]

This issue has been migrated to GitHub.

It can be found at https://github.com/google/guava/issues/<issue id>

Original comment by cgdecker@google.com on 1 Nov 2014 at 4:12

• Added labels: MigratedToGitHub

[GoogleCodeExporter]

Original comment by cgdecker@google.com on 1 Nov 2014 at 4:17

• Changed state: Migrated

[GoogleCodeExporter]

Original comment by cgdecker@google.com on 3 Nov 2014 at 9:08

• Added labels: Restrict-AddIssueComment-Commit