HTTP header SMCLIENTLOCALE vs. Accept-Language

Products

• SITEMINDER
• CA Single Sign On Agents (SiteMinder)
• CA Single Sign On Secure Proxy Server (SiteMinder)

Issue/Introduction

SMCLIENTLOCALE does not seem to work when HTTP header Accept-Language also is being passed for a multi language page.  All browsers generally automatically pass HTTP header Accept-Language.

According to the documentation, SMCLIENTLOCALE Header should take precedence over Accept-Language Header.

Environment

Release : 12.8

Component : SITEMINDER -Access Gateway 12.8.6 

IIS agent: 12.52 sp1 cr10

Cause

Product defect.

Currently SiteMinder collects Locales HTTP header from browser in the order of Client Locale Header, Accept Language Header and the followed by ServerLocale.
However, these values are internally stored in a map and the map stores the values in a sorted order of key.

Even through values are collected in the right order, values are stored in a sorted order.
The result of that is if Accept-Language Header is present, it will always take precedence over any other key.

Only when Accept-Language is not available, then SMCLIENTLOCALE would take precedence.

The code fix will ensure the order in the storage is consistent with the documentation description. 

Which is:

HTTP header SMCLIENTLOCALE
HTTP header Accept-Language
Response header variable SMSERVERLOCALE
The DefaultLocale ACO parameter
The Locale property in the WebAgent.conf file

Resolution

Upgrade to 12.8SP8CR01 Access Gateway to benefit from fix DE541353 (with updated HTTPPlugin.dll or HTTPPlugin.so).

Additional Information

SMCLIENTLOCALE

https://techdocs.broadcom.com/us/en/symantec-security-software/identity-security/siteminder/12-8/configuring/web-agent-configuration/fcc-internationalization.html