Max, Normal relative references are covered now.
We are talking about a relative reference that looks like //otherhost.com/foo/bar.txt why would you do that and not just http://otherhost.com/foo/bar.txt ? I would like a concrete real-world example. Sven > On 05 Feb 2015, at 18:32, Max Leske <[email protected]> wrote: > >> >> On 05 Feb 2015, at 18:28, Sven Van Caekenberghe <[email protected]> wrote: >> >> Peter, >> >> Thanks for the feedback. (CC-ing the list) >> >>> On 05 Feb 2015, at 18:16, PBKResearch <[email protected]> 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:[email protected]] >>> Sent: 05 February 2015 10:30 >>> To: Pharo Development List >>> Cc: monty; [email protected] >>> 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
