On 14 Feb 2014, at 10:53, Johan Brichau <[email protected]> wrote: > > On 14 Feb 2014, at 10:44, Sven Van Caekenberghe <[email protected]> wrote: > >> On 14 Feb 2014, at 10:34, Johan Brichau <[email protected]> wrote: >> >>> No, because the original request was 'foo%20%2B%20' >>> >>> If it prints it, the + should be encoded again. >> >> Why ? > > The + character in a url is decoded as a space: > > self assert: (ZnPercentEncoder new decode: '+' = ' ')
Hmm, but like I said before, there are different safe sets, depending on the situation. That is was recently added. > So, because I notice that the incoming url is decoded when parsing to a > ZnUrl's path segments, recoded when printed and then again decoded, the > following happens: > - '%2B' (encoding of +) gets decoded to '+' (correct) > - '+' gets encoded as '+' (incorrect) > - '+' gets decoded as ' ' (correct) Where/why/how is it re-encoded and decoded ? Maybe it should happen differently in that particular case. >> How exactly is this creating problems ? > > In Seaside, when you serialize an input form using a jquery ajax request and > you enter a '+' in the input form, the browser correctly encodes the '+' > character to a '%2B' in the request url. > However, because the Zinc server performs the above transformation, the '+' > becomes a ' ' in the incoming value of the Seaside callback. > > The + is not a safe character because it is an encoding of a space. Is there a standard functional Seaside Ajax test that I can use to see this for myself ? Sven
