Bug 65466 - content-type application/json default encoding
Summary: content-type application/json default encoding
Status: RESOLVED INVALID
Alias: None
Product: Tomcat 9
Classification: Unclassified
Component: Catalina (show other bugs)
Version: 9.0.50
Hardware: PC Linux
: P2 normal (vote)
Target Milestone: -----
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-07-27 08:10 UTC by qeepcologne
Modified: 2021-07-27 12:55 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description qeepcologne 2021-07-27 08:10:00 UTC
when making a request with Content-Type:"application/json" (without encoding parameter!) against tomcat (i reproduced it with postman), tomcat changes the request to:
 Content-Type:"application/json;charset=ISO-8859-1"
(in case of tomcat 9, i tried 9.0.50 and 9.0.48, tomcat 10 adding UTF-8 instead).
This is very strange to me, i think headers should not be modified at all.
And according to rfc, json default is UTF-8:
https://datatracker.ietf.org/doc/html/rfc7159

I could fix this by setting the charset of every request explicitly to UTF-8, but if you have clients relying on the standard, it should not be necessary.

expected behavior:
- use the correct default, either the tomcat 10 way or leaving the header unchanged. 
- if not possible (e.g. backward compatibility?) add longer explanation to migration guide if you have clients without json payload without charset that they will break.
Comment 1 Michael Osipov 2021-07-27 08:14:17 UTC
Absolutely valid. Same request for HttpClient https://issues.apache.org/jira/browse/HTTPCLIENT-2159.
Comment 2 Mark Thomas 2021-07-27 09:17:28 UTC
A little clarification is required. Do you mean HTTP request headers or HTTP response headers? Assuming you mean HTTP response headers, how - exactly - is the response created? Is this a static resource or is the response generated dynamically?
Comment 3 qeepcologne 2021-07-27 10:27:35 UTC
request headers - i test request with postman and log headers via org.springframework.web.filter.CommonsRequestLoggingFilter in the backend and found it modified.
Comment 4 Mark Thomas 2021-07-27 11:38:08 UTC
Tomcat doesn't change any incoming headers. I've just confirmed this both with a code review and with the following:

POST /examples/jsp/snp/snoop.jsp HTTP/1.1
Host: localhost:8080
Content-Type: application;json
Content-Length: 20

{
    "key": value
}


The content type reported in the JSP was:
Content type: application;json

Best guess, some other component is wrapping the request.
Comment 5 qeepcologne 2021-07-27 12:25:21 UTC
thanks for checking, if i log it to tomcat access log via "%{Content-Type}i" header is unmodified, probably it happens later in spring magic.
Comment 6 Michael Osipov 2021-07-27 12:55:44 UTC
(In reply to qeepcologne from comment #5)
> thanks for checking, if i log it to tomcat access log via "%{Content-Type}i"
> header is unmodified, probably it happens later in spring magic.

It is very unlikely. Spring with Jackson never write a charset. You likely need to debug this.