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 <sven@stfx.eu> wrote:
On 14 Feb 2014, at 10:25, Johan Brichau <johan@inceptive.be> 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 <sven@stfx.eu> 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.