Hey Sven,

I'm catching up on some reading on the topic [1].
It starts making sense to me :-)
So, it does seem that both WAUrl and ZnUrl treat the '+' incorrectly (as you 
mentioned), leading to this:

(ZnUrl fromString: (ZnUrl fromString: 'http://localhost/?param=foo%2Bbar') 
printString) printString = 'http://localhost/?param=foo%20bar'.
(WAUrl decodePercent: (ZnUrl fromString: 'http://localhost/?param=foo%2Bbar') 
printString) printString = 'http://localhost/?param=foo bar'

[1] 
http://blog.lunatech.com/2009/02/03/what-every-web-developer-must-know-about-url-encoding#Thereservedcharactersaredifferentforeachpart

I learned something new today ;-)
Johan

On 14 Feb 2014, at 16:47, Johan Brichau <[email protected]> wrote:

> 
> On 14 Feb 2014, at 12:11, Sven Van Caekenberghe <[email protected]> wrote:
> 
>> $+ is handled in any usage of ZnPercentEncoder, independent of context and 
>> safeSet. That is not right, it is only valid in the context of 
>> application/x-www-form-urlencoded get/post requests:
>> 
>> http://en.wikipedia.org/wiki/Percent-encoding#The_application.2Fx-www-form-urlencoded_type
>> 
>> Outside of that specific use case, $+ becomes space, should not be done, I 
>> think.
>> 
>> OK, now I have something concrete to work with.
> 
> Well... WAUrl does exactly the same: it always replaces a $+ with a space. If 
> what you say regarding $+ being a safe character (I'm not the expert), then 
> it's part of the problem because a WAUrl instance is constructed from a ZnUrl 
> printString. If a ZnUrl prints a $+ where it originally was constructed from 
> a %2B, then it will still fail. 
> 
> I might we wrong, but I keep having the impression it's the (non-)encoding of 
> a $+ that is wrong (rather than the decoding of $+ to space). 
> If you create a url as follows:
>       (ZnUrl fromString: 'http://localhost:8080/foo%20%2B%20bar') 
> The internal pathSegments variable of the ZnUrl instance contains a (I think 
> correctly) decoded string 'foo + bar'.
> When this url is printed (more exactly in #printPath:), it prints it as 
> 'foo%20+%20bar', which is strange for me.
> 
> But, as I said, I am not the expert. Though I will have to see where this 
> impacts Seaside on working with other adaptors...
> 
> Johan


Reply via email to