So do you believe if I use a custom implementation for
PageActivationRequestParameter with the use of the java URLEncoder
that could pose potential issues? I've had it implemented locally for
the past week without any issues, but that's not to say once it's in
production the user base won't find a
The main motivation behind URLEncoder (side note: really wish I had used
the term "Transcoder" for these things) was because Jetty, Tomcat, and
my-weak-understanding-of the servlet spec didn't agree on how and when
URL-encoded data in the path is decoded.
On Thu, Dec 25, 2014 at 10:49 AM, Thiago
On Wed, 24 Dec 2014 20:09:53 -0200, Dmitry Gusev
wrote:
Hi,
as far as I know, Tapestry's URLEncoder allows you to not think about
encoding, it forces to UTF-8.
Yep. In addition, it encodes and decodes null and empty string values,
something java.net.URLEncoder doesn't do, but Tapestry ne
Hi,
as far as I know, Tapestry's URLEncoder allows you to not think about
encoding, it forces to UTF-8.
Default URLEncoder asks you to specify encoding as a separate parameter,
which you normally pass as another URL parameters, for example, look at
ie/oe parameters that Safari adds to Google requ
