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 ? 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 <[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. >>> >>> >> >> > >
