users@javaserverfaces-spec-public.java.net

[jsr344-experts mirror] Query string encoding in outcomes

From: Christian Kaltepoth <christian_at_kaltepoth.de>
Date: Tue, 26 Feb 2013 16:20:28 +0100

Dear experts,

I ran into an issue regarding query parameter encoding in navigation
outcomes while working on PrettyFaces/Rewrite which I want to bring up here.

I did some experiments with Mojarra and MyFaces to find out how they handle
query parameters in outcomes. The result was that both implementations
require the user to _not_ do any URL encoding in the outcome. This means
for example, that non-ASCII characters have to be included in their plain
Unicode representation:

  return "/some-view.xhtml?faces-redirect=true&myParam=ä€öü";

Although this makes sense from the user perspective, this is a very
uncommon representation of a query string. Usually non-ASCII and some
reserved ASCII characters are percent-encoded. The main reason for this is
that some characters have special meaning in a query string and therefore
may break it if not correctly encoded. If you for example want to specify
the value "R&D" in the outcome mentioned above, it will look like this:

  return "/some-view.xhtml?faces-redirect=true&myParam=R&D";

Both Mojarra and MyFaces tread the "&" character in the query parameter
value as a separator and fail to parse the query string resulting in the
value "R" instead of "R&D" for the parameter.

In my opinion there are two things that should be addressed:

   - The spec should clarify that query parameters in outcomes must not be
   percent-encoded. Currently the spec only uses the term "query string" in
   section 7.4.2 without a single word on encoding. And as the
   percent-encoding is the standard case on the web, a note regarding this
   would be very useful.
   - Currently it is impossible to use a "&" character as a view parameter
   value. I know that using this character is a rare case, but using it today
   leads to very weird behavior as described above. Perhaps the spec could
   define how to deal with such a case. Perhaps it would make sense to also
   support percent-encoded values inside the outcome? But this should be
   subject of further discussion.

Thank you very much for your time.

Best regards

Christian Kaltepoth



-- 
Christian Kaltepoth
Blog: http://blog.kaltepoth.de/
Twitter: http://twitter.com/chkal
GitHub: https://github.com/chkal