When connecting to the third-party server for remote Portal authentication, there was a character conversion issue that caused the page to redirect forcefully
- 0 Followed
- 0Collected ，641Browsed
Network Topology
Null
Problem Description
During remote Portal authentication, there was an issue of forced character conversion when the page was redirected.
Process Analysis
Starting from version R5431 and onwards, according to the RFC 3986 protocol requirements, some special characters are encoded as %XX. However, some third-party servers do not recognize the escaped characters, which leads to issues with the page popping up, and the page can be opened normally after manually entering the escaped URL on the terminal. The problem lies in the server-side recognition of the URL.
|
RFC 3986 URI Generic Syntax January 2005 URIs that differ in the replacement of an unreserved character with its corresponding percent-encoded US-ASCII octet are equivalent: they identify the same resource. However, URI comparison implementations do not always perform normalization prior to comparison (see Section 6). For consistency, percent-encoded octets in the ranges of ALPHA (%41-%5A and %61-%7A), DIGIT (%30-%39), hyphen (%2D), period (%2E), underscore (%5F), or tilde (%7E) should not be created by URI producers and, when found in a URI, should be decoded to their corresponding unreserved characters by URI normalizers. ers.
|
Here it is explained that if the URL contains an underscore, the protocol requires it to be encoded as %5F.
Solution
You can resolve this issue by modifying the server-side mechanism, or upgrading the AC to version R5449P01 or above and configuring the special character not to be escaped using the portal url-unescape-chars command.