I had the problem with both, Tomcat 6 and Jetty 7
--
David Germán Canteros
2012/1/16 Howard Lewis Ship
> Tapestry's URLEncoder should probably be deprecated.
>
> It was an attempt to smooth the differences between Tomcat and Jetty
Tapestry's URLEncoder should probably be deprecated.
It was an attempt to smooth the differences between Tomcat and Jetty,
where they did different things w.r.t. URLDecoding. I honestly can't
remember which did which, but basically one would decode the path and
query parameters automatically, and
Aha! I knew there was already a JIRA filed for this. Just voted got it.
On Jan 16, 2012, at 2:40 PM, David Canteros wrote:
> I have the same problem with Tapestry ULREncoder and the W3C standards
> URLs. I think it must follow the standar way because this brings headaches
> when the programm
I have the same problem with Tapestry ULREncoder and the W3C standards
URLs. I think it must follow the standar way because this brings headaches
when the programmer dont known about the internal stuff of tapestry.
I have filed a Jira for this https://issues.apache.org/jira/browse/TAP5-1803
Regar
On Mon, 16 Jan 2012 15:45:52 -0200, Lenny Primak
wrote:
or rather *not* adhering to W3C standards :)
I agree that at least with query parameters Tapestry should use the
standard URL encoding, except maybe for the cases of encoding null values.
--
Thiago H. de Paula Figueiredo
Independen
On Mon, 16 Jan 2012 15:48:50 -0200, Jochen Frey
wrote:
Thanks for pointing that out, Thiago - that hadn't occurred to me.
:)
I assume binding my own implementation in the AppModule should do that.
Let's hope I'm not breaking anything fundamental in the process :)
I don't think it will
Thanks for pointing that out, Thiago - that hadn't occurred to me.
I assume binding my own implementation in the AppModule should do that. Let's
hope I'm not breaking anything fundamental in the process :)
Does anyone know why $ encoding was chosen over %-encoding?
Thanks!
Jochen
On Jan
or rather *not* adhering to W3C standards :)
On Jan 16, 2012, at 12:44 PM, Lenny Primak wrote:
> Tapestry's URLEncoder isn't the best implementation, I agree.
> But the bug that you are referring to was indeed fixed.
> As Thiago *just* answered, your solution would probably be
> to put in your ow
Tapestry's URLEncoder isn't the best implementation, I agree.
But the bug that you are referring to was indeed fixed.
As Thiago *just* answered, your solution would probably be
to put in your own URLencoder.
Also, you can open up a new JIRA issue about Tapestry's URLencoder
now adhering to the W3C
On Mon, 16 Jan 2012 15:21:10 -0200, Jochen Frey
wrote:
Unfortunately (for me), I get this parameter passed from non-Tapestry
code, and the rest of the internet uses %-encoding
(http://tools.ietf.org/html/rfc3986#section-2), which makes this a
problem for me, especially since this seems t
I see what you're saying, you are using Tapestry's URLEncoder. When I do that,
j...@gmail.com becomes: joe$0040gmail.com
When I pass that like this: /thanks?email=joe$0040gmail.com it indeed works.
Unfortunately (for me), I get this parameter passed from non-Tapestry code, and
the rest of the
I do the same thing (but have embedded slashes (/) instead of the '@' sign)
and it works perfectly.
On Jan 16, 2012, at 11:47 AM, Jochen Frey wrote:
> That's exactly what I did (see my example below where I show the encoded
> parameter), which is why the email is sent as: /thanks?email=joe%40gma
That's exactly what I did (see my example below where I show the encoded
parameter), which is why the email is sent as: /thanks?email=joe%40gmail.com
(and not as j...@gmail.com), but it still breaks.
It looks to me like https://issues.apache.org/jira/browse/TAP5-1768 may not be
fixed (or not
The query parameter needs to b e URLencoded otherwise it won't pass validation,
which is exactly what happens in your code. Use URLencoder.encode() or similar.
On Jan 16, 2012, at 12:23 AM, Jochen Frey wrote:
> Hi!
>
> I am using a form to get e-mail signups into salesforce.com. This mecha
Hi!
I am using a form to get e-mail signups into salesforce.com. This mechanism
requires to pass a callback URL which salesforce redirects the browser to on
completion of the action. I want this callback to have the signup email as a
query parameter:
... /thanks?email=joe%40gmail.com
15 matches
Mail list logo
