search

google / guava

Google core libraries for Java
Apache License 2.0
50.04k stars 10.86k forks source link

Add MediaType.FORM_DATA #1560

Open gissuebot opened 9 years ago

gissuebot commented 9 years ago

Original issue created by Ash2kk on 2013-10-21 at 10:25 AM

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

gissuebot commented 9 years ago

Original comment posted by Ash2kk on 2013-10-21 at 10:28 AM

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.

gissuebot commented 9 years ago

Original comment posted by cgdecker@google.com on 2013-10-21 at 01:55 PM

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

Owner: gak@google.com

gissuebot commented 9 years ago

Original comment posted by gak@google.com on 2013-10-21 at 04:36 PM

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?

gissuebot commented 9 years ago

Original comment posted by cpovirk@google.com on 2013-10-21 at 04:40 PM

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

gissuebot commented 9 years ago

Original comment posted by cgdecker@google.com on 2013-10-21 at 05:07 PM

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.

gissuebot commented 9 years ago

Original comment posted by Ash2kk on 2013-10-22 at 03:27 AM

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.

gissuebot commented 9 years ago

Original comment posted by Ash2kk on 2013-10-22 at 07:48 AM

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).

gissuebot commented 9 years ago

Original comment posted by gak@google.com on 2013-10-22 at 05:47 PM

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.

ronshapiro commented 5 years ago

https://github.com/google/guava/blob/9afafaaabb7c19ac21871c0730f1ab1497d7349e/guava/src/com/google/common/net/MediaType.java#L405

cowwoc commented 5 years ago

@ronshapiro Why was this issue closed? It is not fixed.

MediaType.FORM_DATA is actually application/x-www-form-urlencoded not multipart/form-data as users probably expect.

  1. Please rename MediaType.FORM_DATA to FORM_URLENCODED as previously suggested.
  2. Please add MediaType.FORM_DATA having type multipart/form-data (without a boundary)

Let me know if I missed anything. Thank you in advance.

pnagar1705 commented 4 months ago

Hi, do we know if there is a specific Media Type for multipart/form-data with boundary?