[Seaside] WAUrl class>>#decodePercent:

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 
.encodeURI().
.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

Joachim

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
>>>>> be
>>>>> decoded before it can be processed. AFAIK, VAST cannot do that yet -
>>>>> which
>>>>> 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
>>> request.
>> Yes
>>
>>> 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.
>>
>>> 3.) How do others who wrote their jQuery plugins in plain JavaScript handle
>>> 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.
>
> Cheers
> Philippe
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>

-- 
-- 
----------------------------------------------------------------------- 
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