On 14 Feb 2014, at 10:34, Johan Brichau <johan@inceptive.be> wrote:
No, because the original request was 'foo%20%2B%20'
If it prints it, the + should be encoded again.
Why ? Here, but also in most of my other packages, the parsers are more lenient than the specs, to support common practice, but stricter when generating output. 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. WAUrl does it indeed, but that is because it considers $+ unsafe, which is not correct (Zn did that as well before, in the 'better safe than sorry' philosophy). How exactly is this creating problems ?
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.