Closed asialjim closed 1 year ago
From what I can tell, that Content-Type
is illegal according to RFC 2045, which MediaType
conforms to. A property for a media type is of the form attribute=value
and the attribute cannot contain a space under any circumstances. The value can only contain a space if it's quoted.
A space seems to be allowed between the ;
and the parameter though, e.g. multipart/form-data; charset=UTF-8; boundary=--jelsaflflksafjel
. That said, in the time I've been looking at the RFCs I haven't seen anything that obviously states that spaces are allowed there, making me wonder if the RFCs might technically allow spaces around any parts of the syntax (in which case you could also legally write multipart / form-data
, and the space after boundary
could also be considered skippable rather than an invalid part of the parameter's attribute.
One other thing: the class Javadoc for MediaType
states:
Note that this specifically does not represent the value of the MIME Content-Type header and as such has no support for header-specific considerations such as line folding and comments.
So trying to directly parse the value of a Content-Type
header to a MediaType
may not be the right thing to do anyway unless the API returning the string is accounting for and removing things like comments and line folding.
Digging around a little more, it looks like according to RFC 822, whitespace should be allowed around the =
in a parameter (as well as around the /
between the type and subtype, technically at least), though I'm still not 100% clear on that.
Indeed, according to RFC 2045, that content type is illegal, but when I tried to parse it using the corresponding API of the Spring web framework, it also worked properly
org.springframework.http.MediaType mediaType = org.springframework.http.MediaType.valueOf("multipart/form-data;charset=UTF-8;boundary =--jelsaflflksafjel");
System.out.println(mediaType.getCharset());
System.out.println(mediaType);
mediaType = org.springframework.http.MediaType.valueOf("multipart/form-data; charset = UTF-8;boundary =--jelsaflflksafjel");
System.out.println(mediaType.getCharset());
System.out.println(mediaType);
Console Output
UTF-8
multipart/form-data;charset=UTF-8;boundary=--jelsaflflksafjel
UTF-8
multipart/form-data;charset=UTF-8;boundary=--jelsaflflksafjel
So I believe that if we can handle this defect, it will be more robust
As I mentioned in my second comment, I think my initial read was wrong and it actually is legal according to RFC 2045. I'm thinking it should be fine to allow whitespace before and after any of the separators, /
, ;
, and =
.
Yes, it is.
When GuavaAPI parse Content-Type String to GuavaMediaType, there exception happen: Maven Dependency:
Code:
Exception:
When I delete the space charactor between 'boundary' and '=---' like this;
Then It's worked!
By the way, This Content-Type: 'multipart/form-data;charset=UTF-8;boundary =--jelsaflflksafjel' with space charactor was generated by trip framework