I'm the one that got bit by this bug..
tapestry/jetty behave differently on decoding the url..
for example this url:
http://server/page/context%2Fparameter
when the server decodes/interprets this url, should it decode the %2F,
once or twice?? and what would a browser do with that? what does it
mean:? :
page = "page"
context = ["context/parameter"]
or
page = "page"
context = ["context", "parameter"]
So using URLEncoding to encode stuff within a url, is questionable at
best (sadly so), just because the spec/implementation are not strict
about how many times people can/do encode/decode the urls... etc etc.
Now, the format used by howard is definitely verbose in different ways,
but it was the most strict and covered the most cases.. it even
supported null values.. You can always replace it with a simpler
encoding format.. but please do not use just bare URLEncode, or you will
hit this bug eventually :)
Howard Lewis Ship wrote:
The current URLEncoder exists because different servlet contains
interpreted the spec differently, in terms of weather the contents of
the URL are uudecoded before being exposed (via the HttpServetRequest)
to the application.
On Tue, Mar 17, 2009 at 5:59 AM, Thiago H. de Paula Figueiredo
<[email protected]> wrote:
Hi!
I would like to bring a JIRA to your attention:
https://issues.apache.org/jira/browse/TAP5-539. It deals with the
current URLEncoder. IMHO, it has two major problems:
1) It is not compatible with standard URL encoding
2) It produces very ugly URLs for non-7-bit-ASCII characters,
something very annoying any language that has accented characters.
There are some messages in the mailing list concerning this.
Of course, I could implement this myself, but unfortunately I'm not
able to devote any time to Tapestry in the next weeks. :(
--
Thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
