Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
BedrockMission!

Learn More

View all

Sign in to view all badges

UTF-8 fix breaks content-type headers?

Avatar

Avatar
Ignite 10
Level 4
TB3dock
Level 4

Likes

34 likes

Total Posts

203 posts

Correct Reply

4 solutions
Top badges earned
Ignite 10
Boost 25
Give Back 25
Validate 10
Validate 1
View profile

Avatar
Ignite 10
Level 4
TB3dock
Level 4

Likes

34 likes

Total Posts

203 posts

Correct Reply

4 solutions
Top badges earned
Ignite 10
Boost 25
Give Back 25
Validate 10
Validate 1
View profile
TB3dock
Level 4

25-05-2021

By default, AEM queryBuilder, which is how servlets can lookup content, responds with the data encoded in iso-8859 char set instead of the required UTF-8.  The solution, which seems improbable, but works, is to create /osgiconfig/config/org.apache.sling.engine.impl.SlingMainServlet.cfg.json file with the following content:

 

 

{
"sling.additional.response.headers":[
  "X-Content-Type-Options=nosniff",
  "Content-Type=text/html;charset=utf-8",
  "X-Frame-Options=SAMEORIGIN"
  ]
}

 

 

This fixes the queryBuilder returning data with the wrong charset in the servlet, but has the side effect of making the response header always "text/html".  We want our servlets, which are used by the front end to search for and pull page pages as json, to have a content-type of application/json.  however, if we change the above file, it will then break AEM.

We tried overriding the content type in the servlet itself, but this gets ignored (or overwritten).

Any ideas how to support both UTF-8 and application/json just for our servlets?

 

Replies

Avatar

Avatar
Give Back 100
Level 10
asutosh_jena
Level 10

Likes

544 likes

Total Posts

663 posts

Correct Reply

190 solutions
Top badges earned
Give Back 100
Boost 500
Affirm 100
Ignite 1
Establish
View profile

Avatar
Give Back 100
Level 10
asutosh_jena
Level 10

Likes

544 likes

Total Posts

663 posts

Correct Reply

190 solutions
Top badges earned
Give Back 100
Boost 500
Affirm 100
Ignite 1
Establish
View profile
asutosh_jena
Level 10

25-05-2021

Hi @TB3dock 

 

Please check "Apache Sling Request Parameter Handling" configuration in /system/console/configMgr and see what value "sling.default.parameter.encoding" property is holding. If it's set to "ISO-8859-1" please change it to "UTF-8"

Default value should be "UTF-8".

Avatar

Avatar
Ignite 10
Level 4
TB3dock
Level 4

Likes

34 likes

Total Posts

203 posts

Correct Reply

4 solutions
Top badges earned
Ignite 10
Boost 25
Give Back 25
Validate 10
Validate 1
View profile

Avatar
Ignite 10
Level 4
TB3dock
Level 4

Likes

34 likes

Total Posts

203 posts

Correct Reply

4 solutions
Top badges earned
Ignite 10
Boost 25
Give Back 25
Validate 10
Validate 1
View profile
TB3dock
Level 4

25-05-2021

Hi this is for parameter encoding, so has nothing to do with the servlet response I believe. This value was set to UTF-8 when we started.

Avatar

Avatar
Coach
Employee
Jörg_Hoh
Employee

Likes

1,111 likes

Total Posts

3,145 posts

Correct Reply

1,072 solutions
Top badges earned
Coach
Give back 600
Ignite 5
Ignite 3
Ignite 1
View profile

Avatar
Coach
Employee
Jörg_Hoh
Employee

Likes

1,111 likes

Total Posts

3,145 posts

Correct Reply

1,072 solutions
Top badges earned
Coach
Give back 600
Ignite 5
Ignite 3
Ignite 1
View profile
Jörg_Hoh
Employee

25-05-2021

I just checked and the encoding for the output of /bin/querybuilder.json is set to UTF-8 since ages explicitly. What AEM version are you using?

Avatar

Avatar
Ignite 10
Level 4
TB3dock
Level 4

Likes

34 likes

Total Posts

203 posts

Correct Reply

4 solutions
Top badges earned
Ignite 10
Boost 25
Give Back 25
Validate 10
Validate 1
View profile

Avatar
Ignite 10
Level 4
TB3dock
Level 4

Likes

34 likes

Total Posts

203 posts

Correct Reply

4 solutions
Top badges earned
Ignite 10
Boost 25
Give Back 25
Validate 10
Validate 1
View profile
TB3dock
Level 4

26-05-2021

Its the cloud version. Without that content type setting, anything we read from query builder is in iso-8859, even if writing to log files or writing to response. With the setting, we get utf-8, but lose the ability to set the content type to application/json which is a real pain.

Avatar

Avatar
Coach
Employee
Jörg_Hoh
Employee

Likes

1,111 likes

Total Posts

3,145 posts

Correct Reply

1,072 solutions
Top badges earned
Coach
Give back 600
Ignite 5
Ignite 3
Ignite 1
View profile

Avatar
Coach
Employee
Jörg_Hoh
Employee

Likes

1,111 likes

Total Posts

3,145 posts

Correct Reply

1,072 solutions
Top badges earned
Coach
Give back 600
Ignite 5
Ignite 3
Ignite 1
View profile
Jörg_Hoh
Employee

03-06-2021

When you say "it's the cloud version", you mean the version hosted at Adobe or the SDK running on your local machine?

Avatar

Avatar
Ignite 10
Level 4
TB3dock
Level 4

Likes

34 likes

Total Posts

203 posts

Correct Reply

4 solutions
Top badges earned
Ignite 10
Boost 25
Give Back 25
Validate 10
Validate 1
View profile

Avatar
Ignite 10
Level 4
TB3dock
Level 4

Likes

34 likes

Total Posts

203 posts

Correct Reply

4 solutions
Top badges earned
Ignite 10
Boost 25
Give Back 25
Validate 10
Validate 1
View profile
TB3dock
Level 4

03-06-2021

its the cloud SDK running locally, but I assume its the same issue on the hosted version.  Ultimately, both have to work, and currently I can only chose between getting a UTF-8 char response, or a JSON response, I cant have both which is an issue for the API integrations which expect application/json response type.

Avatar

Avatar
Coach
Employee
Jörg_Hoh
Employee

Likes

1,111 likes

Total Posts

3,145 posts

Correct Reply

1,072 solutions
Top badges earned
Coach
Give back 600
Ignite 5
Ignite 3
Ignite 1
View profile

Avatar
Coach
Employee
Jörg_Hoh
Employee

Likes

1,111 likes

Total Posts

3,145 posts

Correct Reply

1,072 solutions
Top badges earned
Coach
Give back 600
Ignite 5
Ignite 3
Ignite 1
View profile
Jörg_Hoh
Employee

03-06-2021

I am very sure that the hosted environments run in an fully UTF-8-ified environment, so there must not be any other encoding. Also I am not aware of any other report of broken encoding in this code, you are the first one. Can you please check your local character encoding and also please validate on a DEV environment in CS, if you see the behavior there as well?