@Consumes parses then drops media type header parameters

using jersey 2.23 (via dropwizard) this runs and works:

```
@POST
@Consumes("application/vnd.my-api.v0.1+json")
public Response test01() {
return Response.ok("XXXXXXXXXX 0.1").build();
}

@POST
@Consumes("application/vnd.my-api.v0.2+json")
public Response test02() {
return Response.ok("XXXXXXXXXX 0.2").build();
}

```

but this won't even start up
```
@POST
@Consumes("application/vnd.my-api+json;r=1.2.3")
public Response test123() {
return Response.ok("XXXXXXXXXX 1.2.3").build();
}

@POST
@Consumes("application/vnd.my-api+json;r=1.2.4")
public Response test124() {
return Response.ok("XXXXXXXXXX 1.2.4").build();
}
```

I appreciate that if it's going to fail it does so early, but I don't see why it should fail. I get this error:
> Caused by: org.glassfish.jersey.server.model.ModelValidationException: Validation of the application resource model has failed during application initialization.
[[FATAL] A resource model has ambiguous (sub-)resource method for HTTP method POST and input mime-types as defined by"@Consumes" and "@Produces" annotations at Java methods public javax.ws.rs.core.Response com.my-api.EntryPointResource.test123() and public javax.ws.rs.core.Response com.my-api.EntryPointResource.test124() at matching regular expression /test. These two methods produces and consumes exactly the same mime-types and therefore their invocation as a resource methods will always fail.; source='org.glassfish.jersey.server.model.RuntimeResource@3c904f1e']

https://jersey.github.io/documentation/latest/jaxrs-resources.html#d0e2246 doesn't seem to have anything about this, and it points to https://jersey.github.io/apidocs-javax.jax-rs/2.1/javax/ws/rs/Consumes.html which gives me a 404.

I'm willing to believe that there's some documentation on this, but the jersey doc pages aren't all there.

The way I read https://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7 says that media types are separated by commas, and have parameters separated using semi-colons. As it says elsewhere (under the Accept header):

> Accept: audio/*; q=0.2, audio/basic
>
> SHOULD be interpreted as "I prefer audio/basic, but send me any audio type if it is the best available after an 80% mark-down in quality."

The thing that surprises me about this is that something is clearly parsing the media type, then dropping information from it.

Please let me know if there's anything else that I can get you for this, or if you have any questions, suggestions, concerns,...

Thank you very much.