Addendum: I suspect that this practice will prevent CORS problems. If a page uses https to get the script for instance and the script calls another url on the same server but with http only, the request will fail (that’s a known problem with some of the Facebook scripts).
> On 05 Feb 2015, at 20:13, Max Leske <maxle...@gmail.com> wrote: > > >> On 05 Feb 2015, at 19:24, Sven Van Caekenberghe <s...@stfx.eu >> <mailto:s...@stfx.eu>> wrote: >> >> Max, >> >> Normal relative references are covered now. >> >> We are talking about a relative reference that looks like >> >> //otherhost.com/foo/bar.txt <http://otherhost.com/foo/bar.txt> > > That’s what I’m talking about. Pinterest for example, requires one to use > this script (https://developers.pinterest.com/on_hover_pin_it_buttons/ > <https://developers.pinterest.com/on_hover_pin_it_buttons/>): > > <script type="text/javascript" src="//assets.pinterest.com/js/pinit.js > <http://assets.pinterest.com/js/pinit.js>" > data-pin-hover="true" > ></script> > > And when you look at that script, it loads another script, again via relative > url. > > Did I misread something? > > Cheers, > Max > >> >> why would you do that and not just >> >> http://otherhost.com/foo/bar.txt <http://otherhost.com/foo/bar.txt> >> >> ? >> >> I would like a concrete real-world example. >> >> Sven >> >>> On 05 Feb 2015, at 18:32, Max Leske <maxle...@gmail.com >>> <mailto:maxle...@gmail.com>> wrote: >>> >>>> >>>> On 05 Feb 2015, at 18:28, Sven Van Caekenberghe <s...@stfx.eu >>>> <mailto: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 >>>>> <mailto: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' <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 <mailto:s...@stfx.eu>] >>>>> Sent: 05 February 2015 10:30 >>>>> To: Pharo Development List >>>>> Cc: monty; pe...@pbkresearch.co.uk <mailto: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 >>>>> <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 >> >> >
