When I tested this back in 2012 (when Jenkins was Hudson) by wgetting http://localhost:8080/..., I saw 'Content-Type: text/plain;charset=ISO-8859-1'. I added a workaround in my reverse proxy (Apache):

<Location "/hudson/job/ivija-update-translations/lastSuccessfulBuild/artifact/diff.txt">
Header set Content-Type "text/plain; charset=UTF-8"
</Location>

When I switched from Hudson to Jenkins, I removed the workaround, tried it again, got garbage again, reinstalled the workaround.

When I do the same test today against Jenkins 1.581, wget shows me 'Content-Type: text/plain'. So, good news: Jenkins is not adding an incorrect ISO-8859-1 charset. Bad news: Jenkins is not adding the correct UTF-8 charset.

The HTTP/1.1 standard says that

When no explicit charset parameter is provided by the sender, media subtypes of the "text" type are defined to have a default charset value of "ISO-8859-1" when received via HTTP. Data in character sets other than "ISO-8859-1" or its subsets MUST be labeled with an appropriate charset value.

So by not providing the correct charset Jenkins is implying the data is in ISO-8859-1.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira

--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to