No, because the original request was 'foo%20%2B%20' If it prints it, the + should be encoded again.
On 14 Feb 2014, at 10:31, Sven Van Caekenberghe <[email protected]> wrote: > > On 14 Feb 2014, at 10:25, Johan Brichau <[email protected]> wrote: > >> Hey Sven, >> >> From what I traced already, the path segments are correctly stored. The >> parsing works fine. >> It's the printing of a ZnUrl that seems to ignore it and produce a >> 'foo%20+%20bar' > > But that is correct, no ? > > ZnResourceMetaUtils urlPathSafeSet includes: $+ > > + is a normal URL path character, Character space is not. > > It is possible that Zn did something else earlier, but now it is (more) > correct ;-) > >> Diving into it... >> >> Johan >> >> On 14 Feb 2014, at 10:11, Sven Van Caekenberghe <[email protected]> wrote: >> >>> Again, I think this can be simplified to URL parsing. >>> >>> 'http://localhost/foo+%2B+bar' asZnUrl. >>> >>> => 'http://localhost/foo%20+%20bar' >>> >>> 'http://localhost/foo+%2B+bar' asZnUrl firstPathSegment. >>> >>> => 'foo + bar' >>> >>> But I think it is correct, unless you read the specs differently. There >>> were indeed some recent , under the hood changes to which characters are >>> allowed in which part of URLs, I did that together with Jan van de Sandt, >>> and we thought we had everything covered, but it is hard to be sure. See >>> >>> ZnUrl>>#encodePath:on: >>> ZnUrl>>#encodeQuery:on: >>> >>> to get started. >> >> > >
