[Seaside] WAUrl class>>#decodePercent:
philippe.marschall at gmail.com
Fri Aug 30 10:45:19 UTC 2013
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.
> 4.) Maybe the right question to the wrong list: how can I decodeURI: in
WAUrl decodePercent: but Seaside should do this for you.
More information about the seaside