"Hitting the JCR directly" I.E. No Exporter:
http://localhost:8080/content/bar.0.json for a JCR dump via Sling.
It looks like this is a result of the Export Servlet not setting any
character encoding, and only setting the content type. Both are needed,
otherwise `charset` defaults to ISO-8859-1 wh
I'm not sure what you mean by "Hitting the JCR directly..." since JCR has
no HTTP support.
In any case, as I said, the ExportServlet doesn't do any special handling
with the content type and the ITs show that application/json is being set,
so I would suggest using a debugger against your instance
I'm accessing Sling (AEM) directly on port 4502. I can put together a test
project with Sling and see if it makes a difference.
If you look at the getResponseContentType method [0], you can see this does
not include the charset.
Is it getting set somewhere else or being defaulted? Hitting the JCR
Hi Chris,
Are you sure that the charset is being added by Sling, i.e. are you
accessing Sling directly or via an Apache server?
The Export Servlet doesn't actually try to infer anything about the content
type header. It just sets it to request.getResponseContentType(). See
[1]. If you trace that b
I've constructed a Sling Model Exporter with very basic options [0], and it
seems to be outputting:
Content-Type: application/json; charset=ISO-8859-1
This breaks the JSON RFC [1] as the default character encoding. It should
be:
Content-Type: application/json; charset=UTF-8
I'm hoping there's a
