On 05 Feb 2015, at 19:24, Sven Van Caekenberghe <sven@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

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 <maxleske@gmail.com> wrote:

On 05 Feb 2015, at 18:28, Sven Van Caekenberghe <sven@stfx.eu> wrote:

Peter,

Thanks for the feedback. (CC-ing the list)

On 05 Feb 2015, at 18:16, PBKResearch <peter@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:sven@stfx.eu]
Sent: 05 February 2015 10:30
To: Pharo Development List
Cc: monty; peter@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