I think we are getting somewhere (it is about time). $+ 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. I still would like to be able to run the Seaside Ajax functional test though. On 14 Feb 2014, at 11:42, Johan Brichau <[email protected]> wrote: > > On 14 Feb 2014, at 10:44, Sven Van Caekenberghe <[email protected]> wrote: > >> So any percent-encoded character is accepted [ but being encoded means that >> its meaning as structuring element is lost, consider $/ ], not necessarily >> encoded on output. > > Right, but here the exact opposite happens. > A reserved character (+) was included as an encoded character (%2B), gets > correctly decoded by Zinc but then never gets encoded again when printing the > url, hence become a structuring element representing a space in the printed > url. > > Because a WAUrl is constructed from incoming ZnUrl's printString, the WAUrl > gets to read the '+' instead of the '%2B'. > > The following code snippet is now true, but should be false imho: > > (ZnUrl fromString: (ZnUrl fromString: 'http://localhost/?param=foo%2Bbar') > printString) printString = 'http://localhost/?param=foo%20bar' > > Johan
