org.eclipse.jetty.http converts incoming content type "application/json; charset=utf-8" to uppercase charset=UTF-8

[gjoshi86]

Jetty 9.4.50.v20221201

OpenJDK 8u292 (1.8.0_292-b10)

When client sends POST call with Content-Type "application/json; charset=utf-8", it reaches our application which uses Jetty 9.4.50.v20221201 and converts it to "application/json; charset=UTF-8" with uppercase.

I debugged the Jetty-http project and found that org.eclipse.jetty.http.HttpParser class has CACHE field. While parsing Content-Type, it uses getBest() method, to get the best match and returns charset=UTF-8 with uppercase.

I know, I am using older version of Jetty which is end of support. I just need your inputs on following queries.

1. Need to know why it is returning the uppercase UTF-8, even if client has send with utf-8 lowercase?
2. What are the implication of setting org.eclipse.jetty.http.HttpParser.STRICT to true which is compliance mode = LEGACY
3. Are there any other ways, we can get the UTF-8 in same format it was sent in the request from the client?

[olamy]

Hi,
Just to let you know
Jetty 9.x is EOL see #7958
Jetty 10/11 is EOL as well #10485

Can you try to reproduce your issue with Jetty 12?

For commercial support of Jetty, see above listed issues.

[gregw]

I think you have answered your own question. It is a case insensitive cache of common header values. There are compliance modes that you can use to bypass the cache and keep the case.... But you should not need to add charsets should be case insensitive.

Note there are fine grained compliance mode controls, so you don't need to go all the way to fill Legacy mode.

That's about all we can say for an end of life release

[joakime]

Also note, that the mime-type application/json has no charset, and using a charset on it has no meaning.
It is always UTF-8, 100% of the time, in all cases.

[gjoshi86]

@gregw @joakime Thank you for your response! This is helpful.

I have couple of questions before I close this ticket.
1. I just need confirmation that the CACHE implementation in org.eclipse.jetty.http.HttpParser is for performance
optimization. Is that right?
2. I have a question around "Note there are fine grained compliance mode controls, so you don't need to go all the way to
fill Legacy mode." - I tried different compliance mode like RFC7230, RFC2616 etc but it works only in case of LEGACY
compliance mode. I think the property (org.eclipse.jetty.http.HttpParser.STRICT = true) kicks in only in case if LEGACY
compliance mode. Secondly, Is it possible to set LEGACY mode only for specific header like Content-Type?

[gregw]

@gjoshi86 The cache is indeed an optimization to avoid many copies of the same string being created and also to allow fast lookup of the actual semantics.

For fine grained compliance in jetty-9, you will need to use one of the CUSTOM modes configured with a system property. See the HttpCompliance class for more detail