[Seaside] WAUrl class>>#decodePercent:
jtuchel at objektfabrik.de
jtuchel at objektfabrik.de
Fri Aug 30 19:27:47 UTC 2013
Okay, this message costs me some courage now ;-)
Philippe, of course Seaside is decoding. Otherwise I would never have
gotten an Exception from decodePercent: in the first place. So I am
expecting the right thing from Seaside and am getting it.
The real problem in my case is that I am using ISO-8859-15 in my
application. So the result of getting the text field's contents using
val() is an ISO-8859-15 encoded String.
encodeURI and encodeURIComponent not only escape characters, but also
convert special characters into UTF-8. In my case this were German
umlauts. So I fell hostage to a side effect of encodeURI and the fact
that VA ST doesn't yet support Unicode and somehow didn't understand this.
So what I did was not wrong per se, I just ignored the whole UTF-8
thing. I should have started my search in that area, because it is not
the first time AJax and its UTF-8 nature bit me.
For Pharo/Squeak/Gemstone users, this UTF-8 stuff is a non-issue, and
therefor readers of my posts had absolutely no chance to see the forest
between all the trees.
All I had to do to make things work was to use .escape() instead of
.escape() does escape special characters in ISO-Latin character sets and
encodes them with %XX. It is the poor man's encodeURI function so to say ;-)
Readers: please be aware that .escape() is not the right solution for
Ajax calls if your server speaks UTF-8. Always try encodeURI first!
Thanks for reading and answering. I would not have dug as deep as I did
without your inspiration and sparks. They all made me see clear after a
while and helped me solve my problem.
Have a nice weekend
Am 30.08.13 12:48, schrieb Philippe Marschall:
> On Fri, Aug 30, 2013 at 12:45 PM, Philippe Marschall
> <philippe.marschall at gmail.com> wrote:
>> On Fri, Aug 30, 2013 at 10:43 AM, jtuchel at objektfabrik.de
>> <jtuchel at objektfabrik.de> wrote:
>>> Hi Philippe,
>>> Am 29.08.13 17:18, schrieb Philippe Marschall:
>>>> Ok, so the decoding of this URL fails
>>>> /kontolino?_s=t0JuC1crW9NO2Bw5&_k=8qoE8Ph8YOUaO2a-&19=test% If this indeed
>>>> the raw URL and not already decoded then it is invalid and can therefore not
>>>> be decoded.
>>> Agreed. It is invalid. I know. And therefor, decodePercent: cannot handle
>>> it. So you can either forget my initial bug report or simply throw a better
>>> exception (stating the URL is invalid instead of Stream access fail).
>>> My Problem is that I am unsure whether I am expecting more from Seaside that
>>> it is intended to do.
>> That's intentional. The contract is more or less:
>> You send valid percent encoded URLs and Seaside does the decoding for
>> you. Everything Seaside presents to you is already decoded. You can
>> view the encoded content but have to go through some hoops.
>>> Because if I encodeURI() the input text before I send the Ajax request, the
>>> callback on the server will get '19=test%25' (the encoded url fragment)
>>> instead of 'test%' (a decoded url fragment). Do I really have to decode the
>>> String in an Ajax callback block by hand?
>> No, Seaside should do this for you. In fact the code throwing the
>> exception tries to do exactly this.
>>> Or is this failing on VAST only
>>> and there needs to be added something.
>> Without further information it's hard to say.
>>>>> encodeURI() would solve it as well, but that brings up a new problem,
>>>>> because the String received at the server side then is encoded and has to
>>>>> decoded before it can be processed. AFAIK, VAST cannot do that yet -
>>>>> is another story...
>>>> Decoding the URL is exactly what the code throwing the exception tries
>>>> to do. Are you sure VAST can't do this? If this is true that should
>>>> show up in other places as well like having % in a GET form.
>>>> Can you to to /tests/functional/WAInputGetFunctionalTest and enter
>>>> 'test%' (without '') into "Text Input" and see if that works?
>>> Well, that works, of course. But I think it doesn't prove much. The text
>>> input on form submit travels as contents of the POST request and not as an
>>> URL fragment, like an Ajax request does. At least that is how I interpret my
>>> Firebug output. The text input is transported as 'text%' and is not encoded
>>> at all (Or Firebug is doing something on the fly to display POST arguments).
>> Yes it does. The form method is GET and not POST so the parameters get
>> added to the request URL and not the method body. And Seaside/VASt
>> does the decoding. This suggest that there is not a bug in VASt.
>> From the stack trace you sent it looks as if you're doing a GET and not a POST.
>>> So what all this seems to boil down to is more a question than a bug report:
>>> 1.) I think it is clear now that I should encodeURI() the contents of my
>>> text input field before handing it to the server as a parameter in an AJAX
>>> 2.) I haven't yet found a place in Seaside where the URL or its parameters
>>> of an AJAX request are treated differently than "normal" POST requests. So
>>> maybe I already found the answer to my question which then is "I need to
>>> decode the String by hand". But maybe you have a tip for me where I could
>>> look for such a place.
>> Look for senders of #isXmlHttpRequest but you shouldn't have to do any decoding.
>>> the case? Do they encodeURI() on the client and do they need to decode by
>>> hand on the server? I ask mainly to find out if I am seeing a VAST specific
>>> problem or a general one. And to find out if I am expecting too much from
>>> Seaside (or if I am probably breeding a new feature request for Seaside).
>> encodeURI() on the client is the way to go. Seaside expects valid HTTP requests.
> or encodeURIComponent() depending on your use case.
> seaside mailing list
> seaside at lists.squeakfoundation.org
Objektfabrik Joachim Tuchel mailto:jtuchel at objektfabrik.de
Fliederweg 1 http://www.objektfabrik.de
D-71640 Ludwigsburg http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
More information about the seaside