Hey Sven, Thanks for fixing that. We're close to getting Yesplan working on Pharo3 now. However, yesterday I stumbled upon another problem. It seems that a percent-encoded '+' (i.e. %2B) get eaten by Zinc and converted into a space (ie. %20). The following test fails in latest Zinc but works in a Zinc on Pharo 1.4: | input request | input := 'GET http://localhost/foo+%2B+bar HTTP/1.1', String crlf, String crlf. request := ZnRequest readFrom: input readStream. self assert: (request url pathSegments hasEqualElements: #('foo%20%2B%20bar')). I'm tracing if I can find the actual source of the problem. regards Johan On 13 Feb 2014, at 22:47, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Hi Kris,
I fixed the problem that you reported. It was a regression caused when adding support for parsing mailto: URLs which don't have a // in them. There is now a new explicit test for parsing '/foo:bar' asZnUrl.
Thanks again for reporting this problem!
Sven
In #bleedingEdge:
=== Name: Zinc-Resource-Meta-Core-SvenVanCaekenberghe.31 Author: SvenVanCaekenberghe Time: 13 February 2014, 10:41:58.821615 pm UUID: dee515f8-aff3-4930-8b90-da2b01e1ee33 Ancestors: Zinc-Resource-Meta-Core-SvenVanCaekenberghe.30
Patch ZnUrl>>#parseFrom:defaultScheme: to parse schemes more carefully so that a colon in a path does not mess things up - see also the regression test ZnUrlTests>>#testNoSchemeColonInPath parsing /foo:bar (thanks Kris Gijbels) === Name: Zinc-Resource-Meta-Tests-SvenVanCaekenberghe.19 Author: SvenVanCaekenberghe Time: 13 February 2014, 10:42:42.63619 pm UUID: 264c99fe-52ef-4f4a-8a25-fc870f34cfb2 Ancestors: Zinc-Resource-Meta-Tests-SvenVanCaekenberghe.18
Patch ZnUrl>>#parseFrom:defaultScheme: to parse schemes more carefully so that a colon in a path does not mess things up - see also the regression test ZnUrlTests>>#testNoSchemeColonInPath parsing /foo:bar (thanks Kris Gijbels) ===