[Seaside] WAUrl class>>#decodePercent:
philippe.marschall at gmail.com
Fri Aug 30 10:48:08 UTC 2013
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.
More information about the seaside