The HTTPHeaderEncodingSpec setting affects the encoding of all HTTP header values and all custom HTTP-COOKIE responses.
Use this parameter to support Web applications expecting localized text in specific encodings. Since cookies pass back and forth between the browser and portal through the HTTP protocol, you should use the RFC-2047 HTTPWrapSpec if your chosen encoding puts characters that HTTP traffic considers illegal into the cookies.
For example, some Shift-JIS characters will cause undesirable results if not further encoded by RFC-2047.
For Kanji characters, you can use SECP932, which is a superset of SHIFT-JIS. Though SHIFT-JIS can be used for most Kanji encoding and decoding, CP932 covers an even larger character set.
When HTTPWrapSpec is used, first the data is encoded according to the HTTPHeaderEncodingSpec, then the data is further encoded following the RFC-2047 specification.
The syntax for the parameter is:
encoding_spec, wrapping_spec
The encoding_spec is a text string that represents one of the following encoding types: UTF-8, Shift-JIS, EUC-J, or ISO-2022 JP. Specify the encoding type you want the Agent to use.
The wrapping_spec is the wrapping specification, which must be RFC-2047. Although this variable is optional, we strongly recommend that you include the wrapping specification because the encoding type you choose may generate byte codes that are not compatible with the HTTP protocol.
This is especially true if you use custom HTTP Cookie responses that contain double-byte encoded data. For example, some Shift-JIS characters cause undesirable results if they are not further encoded by RFC-2047. The wrapping also tells the receiving application the type and nature of the encoding so the application can better interpret the encoded text. For example, you may set the parameter to Shift-JIS,RFC-2047.
When RFC-2047 is used, the Agent first encodes the data based on the chosen encoding specification and then further encodes the data following the RFC-2047 specification.
Note: If you leave the HTTPHeaderEncodingSpec setting blank, the default is UTF-8 with no wrapping.
By default, the Web Agent conforms to RFC 2047. However, you can disable this conformance by setting the ConformToRFC2047 parameter to no.
If this parameter does not exist or is set to yes, the Web Agent conforms to RFC 2047.
The SM_AGENTAPI_ATTR_USERMSG response enables developers of custom SiteMinder authentication schemes to return custom text to their client applications, as part of a user challenge or for some other purpose.
Beginning with v5 QMR3, the Web Agent has the ability to convert the text from an SM_AGENTAPI_ATTR_USERMSG response to an SMUSRMSG cookie when performing a forms challenge.
To ensure the SMUSRMSG cookie is removed after the challenge is complete, the FCC consumes the cookie (deletes it from the browser) after a successful POST request, as follows:
Note: The SMUSRMSG cookie will be stored for a period of time in the user's browser, and could possibly be transmitted over non-secure HTTP connections. As a result, sensitive data should be avoided.
Web Agents will URL-encode text that is placed in the SMUSRMSG cookie during a forms challenge, to make it safe for HTTP transmission, eliminating spaces and other harmful characters. The FCC decodes this text before making it available to the environment for use in custom FCC functionality.
Note: URL encoding is not implemented unless the text is placed in the SMUSRMSG cookie.
To implement the new functionality, custom authentication scheme developers must generate custom forms-based authentication schemes. When an Sm_AgentApi_Login() call returns SM_AGENTAPI_CHALLENGE, the Agent challenges the requesting user by redirecting to the authentication scheme URL provided by the response to Sm_AgentApi_IsProtected().
When the Web Agent handles an authentication scheme that uses the HTML Forms authentication scheme template, the Agent looks for a SM_AGENTAPI_ATTR_STATUS_MESSAGE response attribute. If the attribute is found, the Agent generates the appropriate SMUSRMSG cookie, while redirecting to the authentication scheme URL. The FCC may then use this cookie during form generation, if appropriate directives are placed in the desired .FCC source file.
Note: For more information, see the Policy Server documentation.
You can specify which naming convention the Web Agent uses for HTTP headers with the following parameter:
Specifies if the Web Agent uses underscores in HTTP header names. With some web servers (such as the Sun Java System), using the underscore character in the HTTP headers causes problems with some applications.
When this parameter is set to no, the HTTP headers will not have underscores, as shown in the following example:
SMHeaderName
When this parameter is set to yes, the HTTP headers will use underscores, as shown in the following example:
SM_HeaderName
Default: (traditional agents) Yes
Default: (framework agents) No
To enable legacy variables and have the Web Agent use underscores in the HTTP header names, set value of the LegacyVariables parameter to yes.
|
Copyright © 2012 CA.
All rights reserved.
|
|