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 jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to