[Seaside] WAUrl class>>#decodePercent:

[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