Details
-
Type: Bug
-
Status: Closed
-
Priority: Major
-
Resolution: Fixed
-
Affects Version/s: EE-1.8.2.GA_P04
-
Fix Version/s: EE-1.8.2.GA_P05
-
Component/s: Framework
-
Labels:None
-
Environment:ICEfaces
-
Assignee Priority:P1
Description
The implementation of ExternalContext.redirect() encodes the URL that is passed to the method, although it must not. This behavior is not mentioned in the JSF specification, and must not be performed.
If you encode yourself the URL passed in as a String to redirect(), this means that you consider that the URL is not encoded by the caller. Then, how can you correctly parse that URL ? More precisely, if the URL is not encoded, how do you distinguish that the '?' character found in the URL is actually the separator between the path and the query string, or a character in the value of a query string parameter.
As an example, the following URL
/redirector/goto?newUrl=http://some.site.com/pages?id=12
is parsed by BridgeExternalContext into an URI with the following characteristics:
path = /redirector/goto?newUrl=http://some.site.com/pages
querystring = id=12
and then encoded into this:
/redirector/goto%3FnewUrl=http://some.site.com/pages?id=12
This may or may not be correct. Only the client knows it. The client actually makes this clear by encoding the URL before passing it to redirect(). In my example, this means:
/redirector/goto?newUrl=http://some.site.com/pages%3Fid=12
Of course, ExternalContext.redirect() must not re-encode the passed in URL, or we will get something like:
/redirector/goto?newUrl=http://some.site.com/pages%253Fid=12
because %3F is encoded as %253F.
The described encoding issue is indeed incorrect behavior in ICEfaces. However, the original "fix" (
ICE-3427) dated back over 4 years and a recent context parameter was introduced (ICE-8270) in order to be able to disable this encoding. It was discussed that the default of this context parameter might needed to be switched to disable encoding. But due to the incorrect encoding being in there for a long period and user's possible reliance on this old behavior, it was decided to leave the default as is: encode by default. In order to get the correct behavior this context parameter can be set to disable encoding. Marking this one as FIXED.