A while back, Gili asked[1] about the possibility of enhancing the
jersey-multipart APIs to make it easier to deal with parameters. An
example of where this would be handy is a header like:
Content-Type: application/xml; charset=UTF-8
Currently, you can get "application/xml; charset=UTF-8" back as a string
by calling
bodyPart.getHeaders().getFirst("Content-Type")
but that leaves parsing out the parameter names and values as an
exercise left to the reader.
Here is my proposal to enhance the current code to make things like this
easier to deal with. In the BodyPart class, add an *additional* method
with this signature:
public MultivaluedMap<String,ParameterizedHeader>
getParameterizedHeaders()
so that people who don't care about parameters can still use the
underlying string based headers -- plus, they don't have to pay the
parsing overhead unless they actually need it. This also avoids
breaking backwards compatibility for anyone currently using the
jersey-multipart code, since we're not changing any existing method
signatures. Given this call, you can do things like (assuming the
content type header is set as shown above):
ParameterizedHeader header =
bodyPart.getParameterizedHeaders().getFirst("Content-Type");
String contentType = header.getValue(); // Returns "application/xml"
String charset = header.getParameters().get("charset"); // Returns
"UTF-8"
Note that ParameterizedHeader is the class that Paul recently refactored
and created in jersey-core. It has *much* more robust parsing than the
HeaderValues class I was playing with, so we should use
ParameterizedHeader instead.
I've got this implemented (with tests) locally, but wanted to get some
feedback before checking it in. What do you think?
Craig
[1]
http://n2.nabble.com/Hello-World!-and-Welcome-to-jersey-multipart-td1343189.html#a1452334