Re: [Pharo-dev] ZnUrl>>#withRelativeReference:
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.
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
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
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
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 <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" 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
?
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
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 <maxleske@gmail.com> wrote:
On 05 Feb 2015, at 19:24, Sven Van Caekenberghe <sven@stfx.eu <mailto: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 <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 <maxleske@gmail.com <mailto:maxleske@gmail.com>> wrote:
On 05 Feb 2015, at 18:28, Sven Van Caekenberghe <sven@stfx.eu <mailto: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 <mailto: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' <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 <mailto:sven@stfx.eu>] Sent: 05 February 2015 10:30 To: Pharo Development List Cc: monty; peter@pbkresearch.co.uk <mailto: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 <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
2015-02-05 16:18 GMT-03:00 Max Leske <maxleske@gmail.com>:
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).
Exactly. Plus the references are also independent of the requested transport protocol (HTTP or HTTPS), so if the request starts on HTTP and no automatic redirection to HTTPS is applied, all links continue to work, as well as if the first request happens with HTTPS. Regards!
On 05 Feb 2015, at 22:05, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
2015-02-05 16:18 GMT-03:00 Max Leske <maxleske@gmail.com>:
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).
Exactly.
Plus the references are also independent of the requested transport protocol (HTTP or HTTPS), so if the request starts on HTTP and no automatic redirection to HTTPS is applied, all links continue to work, as well as if the first request happens with HTTPS.
Regards!
Yes, makes sense. Now in Zn #bleedingEdge === Name: Zinc-Resource-Meta-Core-SvenVanCaekenberghe.46 Author: SvenVanCaekenberghe Time: 5 February 2015, 10:32:09.544628 pm UUID: 7364336d-5e0f-485b-9c2e-242c33d7a24d Ancestors: Zinc-Resource-Meta-Core-SvenVanCaekenberghe.45 Extend ZnUrl>>#withRelativeReference: to handle network relative references (thanks Peter Kenny & Max Leske for convincing me that this is needed) === Name: Zinc-Resource-Meta-Tests-SvenVanCaekenberghe.32 Author: SvenVanCaekenberghe Time: 5 February 2015, 10:32:28.130956 pm UUID: 28846eea-cd9a-4a27-b54f-d9a1ac171fbd Ancestors: Zinc-Resource-Meta-Tests-SvenVanCaekenberghe.31 Extend ZnUrl>>#withRelativeReference: to handle network relative references (thanks Peter Kenny & Max Leske for convincing me that this is needed) === Sven
On 05 Feb 2015, at 20:13, Max Leske <maxleske@gmail.com> wrote:
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
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/):
<script type="text/javascript" src="//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?
Max, You understood well ;-) OK, thanks for the concrete example. So these are out there in the wild, I'll add a special case to handle these. Thanks, Sven
Cheers, Max
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
participants (3)
-
Esteban A. Maringolo -
Max Leske -
Sven Van Caekenberghe