> On 4 Jun 2018, at 03:48, James Roper <ja...@lightbend.com> wrote:
>
> ...
>
> +1 on variants of getContentType that give you either the media type or the
> charset parsed from the content type header. Without them, we're going to end
> up with a lot of regexps doing ad hoc parsing to get the information needed
> out of the Content-Type header. For example, if you want to know if the
> incoming request is application/json, text/plain, or application/xml, in
> order to parse that correctly, you'll need to do things like
> .matches("text/plain(?;.*)?"). Whereas, if you had a getMediaType() you could
> just do a .equals("text/plain").
I agree that it can be a little cumbersome, but still possible, to get
to the meat of specific header values like Content-Type. There is a
mini-design space around this; should a single method be exposed to
return the Charset, or a higher-level interface like ContentType that
exposes the media-type and the list of parameters, exceptions/defaults,
etc?
I filed the following enhancement request to track this:
https://bugs.openjdk.java.net/browse/JDK-8204470
Since this request is more of a convenience API, and is additive, it may
not happen in time for 11. There are a number of other higher priority
issues that need to be resolved before JDK 11 RDP 1 [1] . Some of these
have minor impact on the existing API, and as such need to be resolved
in 11.
-Chris.
[1] http://openjdk.java.net/projects/jdk/11/
