[
https://issues.apache.org/jira/browse/GEODE-8372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery updated GEODE-8372:
------------------------------
Description:
In a client, CMS accepts only UTF-8 messages from the locator. But the locator
can send non-UTF-8 messages depending on how the JVM and OS are configured.
It looks as if the locator CMS uses the JVM's default character encoding, and
the JVM sets its default character encoding based on the operating system's
default locale.
If a client CMS accepts only UTF-8, the locator CMS should send only UTF-8,
regardless of the JVM's default character encoding.
Example: I have a test client that uses a {{ClientClusterManagementService}} to
create a region. The locator, runs on a machine where the default locale is
us_EN.US-ASCII, sends US-ASCII responses. The client throws an
{{UnknownContentTypeException}}:
{noformat}
org.springframework.web.client.UnknownContentTypeException: Could not extract
response: no suitable HttpMessageConverter found for response type [class
org.apache.geode.management.api.ClusterManagementRealizationResult] and content
type [application/json;charset=US-ASCII]
{noformat}
For testing: On my mac, it's possible to set the encoding for a locator by
setting the {{LC_ALL}} environment variable in the shell before launching the
locator.
For example, if I execute {{export LC_ALL=en_US.US-ASCII}}, then launch a
locator in that shell, the locator sends CMS messages in US-ASCII, as shown in
this {{curl -v}} output:
{noformat}
% curl localhost:7070/management/v1/regions -v
* Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 7070 (#0)
> GET /management/v1/regions HTTP/1.1
> Host: localhost:7070
> User-Agent: curl/7.64.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Tue, 21 Jul 2020 16:28:26 GMT
< Content-Type: application/json; charset=US-ASCII
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Pragma: no-cache
< Expires: 0
< X-Frame-Options: DENY
< Content-Length: 31
< Server: Jetty(9.4.21.v20190926)
<
* Connection #0 to host localhost left intact
{"statusCode":"OK","result":[]}* Closing connection 0
{noformat}
was:
In a client, CMS accepts only UTF-8 messages from the locator. But the locator
can send non-UTF-8 messages depending on how the JVM and OS are configured.
It looks as if the locator CMS uses the JVM's default character encoding, and
the JVM sets its default character encoding based on the operating system's
default locale.
If a client CMS accepts only UTF-8, the locator CMS should send only UTF-8,
regardless of the JVM's default character encoding.
Example: I have a test client that uses a {{ClientClusterManagementService}} to
create a region. The locator, runs on a machine where the default locale is
us_EN.US-ASCII, sends US-ASCII responses. The client throws an exception:
{noformat}
org.springframework.web.client.UnknownContentTypeException: Could not extract
response: no suitable HttpMessageConverter found for response type [class
org.apache.geode.management.api.ClusterManagementRealizationResult] and content
type [application/json;charset=US-ASCII]
{noformat}
For testing: On my mac, it's possible to set the encoding for a locator by
setting the {{LC_ALL}} environment variable in the shell before launching the
locator.
For example, if I execute {{export LC_ALL=en_US.US-ASCII}}, then launch a
locator in that shell, the locator sends CMS messages in US-ASCII, as shown in
this {{curl -v}} output:
{noformat}
% curl localhost:7070/management/v1/regions -v
* Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 7070 (#0)
> GET /management/v1/regions HTTP/1.1
> Host: localhost:7070
> User-Agent: curl/7.64.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Tue, 21 Jul 2020 16:28:26 GMT
< Content-Type: application/json; charset=US-ASCII
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Pragma: no-cache
< Expires: 0
< X-Frame-Options: DENY
< Content-Length: 31
< Server: Jetty(9.4.21.v20190926)
<
* Connection #0 to host localhost left intact
{"statusCode":"OK","result":[]}* Closing connection 0
{noformat}
> Configure CMS to use UTF-8 regardless of JVM default
> ----------------------------------------------------
>
> Key: GEODE-8372
> URL: https://issues.apache.org/jira/browse/GEODE-8372
> Project: Geode
> Issue Type: Bug
> Components: management
> Reporter: Dale Emery
> Priority: Major
>
> In a client, CMS accepts only UTF-8 messages from the locator. But the
> locator can send non-UTF-8 messages depending on how the JVM and OS are
> configured.
> It looks as if the locator CMS uses the JVM's default character encoding, and
> the JVM sets its default character encoding based on the operating system's
> default locale.
> If a client CMS accepts only UTF-8, the locator CMS should send only UTF-8,
> regardless of the JVM's default character encoding.
> Example: I have a test client that uses a {{ClientClusterManagementService}}
> to create a region. The locator, runs on a machine where the default locale
> is us_EN.US-ASCII, sends US-ASCII responses. The client throws an
> {{UnknownContentTypeException}}:
> {noformat}
> org.springframework.web.client.UnknownContentTypeException: Could not extract
> response: no suitable HttpMessageConverter found for response type [class
> org.apache.geode.management.api.ClusterManagementRealizationResult] and
> content type [application/json;charset=US-ASCII]
> {noformat}
> For testing: On my mac, it's possible to set the encoding for a locator by
> setting the {{LC_ALL}} environment variable in the shell before launching the
> locator.
> For example, if I execute {{export LC_ALL=en_US.US-ASCII}}, then launch a
> locator in that shell, the locator sends CMS messages in US-ASCII, as shown
> in this {{curl -v}} output:
> {noformat}
> % curl localhost:7070/management/v1/regions -v
> * Trying ::1...
> * TCP_NODELAY set
> * Connected to localhost (::1) port 7070 (#0)
> > GET /management/v1/regions HTTP/1.1
> > Host: localhost:7070
> > User-Agent: curl/7.64.1
> > Accept: */*
> >
> < HTTP/1.1 200 OK
> < Date: Tue, 21 Jul 2020 16:28:26 GMT
> < Content-Type: application/json; charset=US-ASCII
> < X-Content-Type-Options: nosniff
> < X-XSS-Protection: 1; mode=block
> < Cache-Control: no-cache, no-store, max-age=0, must-revalidate
> < Pragma: no-cache
> < Expires: 0
> < X-Frame-Options: DENY
> < Content-Length: 31
> < Server: Jetty(9.4.21.v20190926)
> <
> * Connection #0 to host localhost left intact
> {"statusCode":"OK","result":[]}* Closing connection 0
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
