Environment
Novell Service Desk 6.5
Situation
It is possible for web servers to override the character set being declared in a web page. If this is in place, the character encoding setting in the system.properties will not apply to the browser.
Resolution
To check if this is occurring, the first step is to telnet to the server in question to see what content is being sent. To do this, the following commands can be issued, replacing 123.123.123.123 with the IP address (or domain/host name) of the server hosting the content.
telnet 123.123.123.123 80
Once connected, the following commands should be issued, where fr is the locale being requested. In this example, this is French, but obviously change that as applicable. For the default website, just omit the whole Accept-Language line.
Note also that after the last line there is a blank new line there. This is required to tell the server that the request is complete
Also be aware that telnet on Windows sends any mistakes that are corrected using the backspace/delete key so that could make the request invalid. Therefore, it is good practice to copy and paste all this text in:
---
GET /Novell Service Desk/WebObjects/Novell Service Desk.woa/ HTTP/1.1
Host: 192.168.1.115
Accept-Language: fr
---
Scroll up to see the initial response received from this request and provided the first line is something like 'HTTP/1.1 200 OK', this means the request worked and looking below this line, through the headers, before the actual web page content begins, see if the following line exists:
Content-Type: text/html,charset=utf-8
In this example the server is telling the browser requesting that the content that will follow is text/html and will be in the utf-8 character set.
Scroll down a little further, near the top of the actual website content, something like this:
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"></meta>
This is Novell Service Desk telling the browser to use iso-8859-1 to display the content. However, because the web server has already declared the content to be in the utf-8 character set, this declaration is being ignored.
The fix for this is to remove the configuration in web server that is causing the character set to be defined in the HTTP headers. Here are the steps for doing this, based on the web server in use...
Apache
In Apache there will be a configuration line beginning
AddDefaultCharset
This line will need commented out by pre-pending it with a #, and then Apache would need restarting.
If not sure which configuration file this is in, the easiest way to find it on a Linux installation would probably be to use the following command:
grep -Rn AddDefaultCharset /etc/
This will display the file names that have this text, the line number and the content of the line.
On Windows it should be possible to use Windows search or install a conversion of the grep command as 2 possible ways to find it.
IIS7
Open IIS Manager and select either the server and/or website in question, then double click on HTTP Response Headers.
If this is present there will be a line with the name 'Content-Type' and somewhere in the value for that entry it will read 'charset=utf-8' (or another character set).
Either the whole charset part needs removing or better still, and certainly if the charset is the only thing being defined here, the Content-Type line can be removed.
IIS6
In IIS Manager, right-click on the website in question, selecting Properties and the HTTP Headers tab. Custom HTTP Headers appear in the box on that page.
Similarly to the IIS7 instructions, look for a line with Content-Type and a charset definition and it will need removing as per the IIS7 steps.
To check if the changes took effect, the telnet test can be used again but, of course, the Novell Service Desk login page can also be revisited in a browser.
telnet 123.123.123.123 80
Once connected, the following commands should be issued, where fr is the locale being requested. In this example, this is French, but obviously change that as applicable. For the default website, just omit the whole Accept-Language line.
Note also that after the last line there is a blank new line there. This is required to tell the server that the request is complete
Also be aware that telnet on Windows sends any mistakes that are corrected using the backspace/delete key so that could make the request invalid. Therefore, it is good practice to copy and paste all this text in:
---
GET /Novell Service Desk/WebObjects/Novell Service Desk.woa/ HTTP/1.1
Host: 192.168.1.115
Accept-Language: fr
---
Scroll up to see the initial response received from this request and provided the first line is something like 'HTTP/1.1 200 OK', this means the request worked and looking below this line, through the headers, before the actual web page content begins, see if the following line exists:
Content-Type: text/html,charset=utf-8
In this example the server is telling the browser requesting that the content that will follow is text/html and will be in the utf-8 character set.
Scroll down a little further, near the top of the actual website content, something like this:
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"></meta>
This is Novell Service Desk telling the browser to use iso-8859-1 to display the content. However, because the web server has already declared the content to be in the utf-8 character set, this declaration is being ignored.
The fix for this is to remove the configuration in web server that is causing the character set to be defined in the HTTP headers. Here are the steps for doing this, based on the web server in use...
Apache
In Apache there will be a configuration line beginning
AddDefaultCharset
This line will need commented out by pre-pending it with a #, and then Apache would need restarting.
If not sure which configuration file this is in, the easiest way to find it on a Linux installation would probably be to use the following command:
grep -Rn AddDefaultCharset /etc/
This will display the file names that have this text, the line number and the content of the line.
On Windows it should be possible to use Windows search or install a conversion of the grep command as 2 possible ways to find it.
IIS7
Open IIS Manager and select either the server and/or website in question, then double click on HTTP Response Headers.
If this is present there will be a line with the name 'Content-Type' and somewhere in the value for that entry it will read 'charset=utf-8' (or another character set).
Either the whole charset part needs removing or better still, and certainly if the charset is the only thing being defined here, the Content-Type line can be removed.
IIS6
In IIS Manager, right-click on the website in question, selecting Properties and the HTTP Headers tab. Custom HTTP Headers appear in the box on that page.
Similarly to the IIS7 instructions, look for a line with Content-Type and a charset definition and it will need removing as per the IIS7 steps.
To check if the changes took effect, the telnet test can be used again but, of course, the Novell Service Desk login page can also be revisited in a browser.
Cause
Web servers can be configured to override the character set being
declared in the HEAD tags of any hosted HTML content. This is done by
declaring the character set first in the headers that precede the web
page content. If this is in place, the character encoding setting in the
system.properties will not apply to the browser as the header content
will supersede it.
For languages bases around the English character set the most likely symptom will be accented characters not displaying correctly.
The first indications of this might be if the browser is selecting a different character encoding than is being declared in the source of the web page. For most browsers, the encoding and source of the page can be found in their menu options.
For languages bases around the English character set the most likely symptom will be accented characters not displaying correctly.
The first indications of this might be if the browser is selecting a different character encoding than is being declared in the source of the web page. For most browsers, the encoding and source of the page can be found in their menu options.
Additional Information
Formerly known as 1001301