> On 05 Feb 2015, at 18:28, Sven Van Caekenberghe <s...@stfx.eu> wrote: > > Peter, > > Thanks for the feedback. (CC-ing the list) > >> On 05 Feb 2015, at 18:16, PBKResearch <pe...@pbkresearch.co.uk> wrote: >> >> Sven >> >> Thanks for your efforts. I have tried ZnUrl>>#withRelativeReference: on the >> examples I gave in my e-mail of 11 Jan. Unfortunately it gives the same >> incorrect result as ZnUrl>>#inContextOf: in the case where the relative >> address begins with '//'. Admittedly this is a rather weird case, but RFC >> 3986 does acknowledge its existence (see para 4.2) and it is dealt with >> correctly by the old Url class>># combine:withRelative: (in fact there is >> special coding for this case in HierarchicalUrl>># >> privateInitializeFromText:). (I am not sure whether the pseudo-code in RFC >> 3986 sec 5 deals correctly with an initial '//'; it is not considered >> explicitly, but I could not follow all the ramifications of the case with >> initial '/'.) > > I would like to understand why you need it, it seems very weird to me, it was > one of the few cases that I decided not to implement: > > In ZnUrlTests>>#testReferenceResolution > > " '//g' -> 'http://g'. " "we do not support relative network path references > (4.2)" > > In the RFC they say (page 26) > > << > A relative reference that begins with two slash characters is termed > a network-path reference; such references are rarely used.
“rarely” is certainly not right today. Most of the social media / maps / blah services provide their scripts with relative references (to fight cross domain request problems I guess?). >>> > > Could you please give a concrete example of how/why this is useful ? > > Thx, > > Sven > >> I feel rather guilty that you have gone to so much trouble because, thanks >> to Monty, I now have two alternatives to the Blanchard parser (XMLHTMLParser >> and Soup). I shall pretty certainly be using one or other of these in >> future, in place of the Blanchard parser, because they provide more flexible >> ways of interrogating the resulting DOM - and also because they are actively >> maintained. So from my point of view there is now no need for you to pursue >> this any further - unless you see this as a loose end to be tidied up. > > Not problem, I am trying to make it right. > >> Thanks again >> >> Peter Kenny >> >> PS I can't post to the Pharo Development List, so I left that out of the >> addressee list. >> >> -----Original Message----- >> From: Sven Van Caekenberghe [mailto:s...@stfx.eu] >> Sent: 05 February 2015 10:30 >> To: Pharo Development List >> Cc: monty; pe...@pbkresearch.co.uk >> Subject: ZnUrl>>#withRelativeReference: >> >> Hi, >> >> I added ZnUrl>>#withRelativeReference: which implements the process >> described in section 5 of RFC 3986. >> >> https://pharo.fogbugz.com/f/cases/14855/Add-reference-resolution-to-ZnUrl >> >> Summary: >> >> In certain contexts (like links on a webpage) partial URLs are used that >> must be interpreted relative to a base URL (like the URL of the webpage >> itself). >> >> Example: >> >> 'http://www.site.com/static/html/home.html' asZnUrl >> withRelativeReference: '../js/menu.js' >> >> => http://www.site.com/static/js/menu.js >> >> This was previously not possible with ZnUrl. >> >> If you know this stuff, please have a look. >> >> Monty ? Peter ? >> >> Sven >> >> PS: this is in #bleedingEdge for now >> > >
