[Seaside] is there url encoding in Seaside or Squeak?

[Merik Voswinkel]

On Oct 3, 2007, at 12:30 PM, Stuart Herring wrote:

> On 9/30/07, Merik Voswinkel <merik at mac.com> wrote:
>> My mistake because I was looking for something to encode the whole
>> url, not one character.
>> After two hours I have found what I was looking for: String>>>
>> encodeForHTTP encodes the whole string:
>>
>> xmlUrl := xmlUrl encodeForHTTP.
>>
>> But it does not encode all (just like Seaside), it does not encode
>> the '_' and the '.' as you can see from this result:
>>
>> xmlPath%3Dhttp%3A%2F%2Fwww.macmerik.nl%3A9090%2Fseaside%2Ftests%
>> 2Ffacade%3F14%26_k%3DzllSchmY%26_s%3DqzSqkxyQfMWoNLdV
>>
>> So I will rewrite it to encode those characters as well, like the
>> tool at http://www.dommermuth-1.com/protosite/experiments/encode/
>> index.html .
>> This tool is written in Flash and does encode the '_' and '.'  also.
>> I need the conversion Flash uses because it is for passing url's with
>> FlashVars to Flash.
>>
>> The question that remains is why some characters are not encoded and
>> others are.
> Why would you encode '_' or '.'?  They have no special meaning in a
> URL or in HTTP and they both fall within the 7 bit ASCII character set
> as standard printable characters.
> Encoding them would produce a needlessly long URL and waste CPU cycles
> at both ends.

It is what FlashVars demand (I think it is typical of Adobe Flash, i  
vastly prefer Open Source Flash)

>
>> From the RFC you quoted above:
>    Thus, only alphanumerics, the special characters "$-_.+!*'(),", and
>    reserved characters used for their reserved purposes may be used
>    unencoded within a URL.
>
> '_' and '.' are explicitly mentioned as not needing to be encoded
>
It still must be done, i tested it. Flashvars is not documented so  
this is how you must find out.
I have it running and implemented a special encodeForHTTPandFlashVars

>> From your examples it's apparent that you don't want _every_  
>> character
> encoded as you're not expecting the standard alpha-numeric characters
> to be encoded, so why underscore and full-stop?

Again, it must be so as the tests prove.

Merik