ZnUrl: Constructing without Scheme
'http://www.hm.com' asUrl host = 'www.hm.com'. All good so far, but: 'www.hm.com' asUrl host = nil. 'www.hm.com' asUrl segments = an OrderedCollection('www.hm.com') I realize presenting a URL without a scheme is kind of vague, but the least surprising thing to me would be to interpret schemeless URLs as starting with the authority. After all, most people commonly use "www.hm.com" as a shorthand for "http://www.hm.com" ----- Cheers, Sean -- View this message in context: http://forum.world.st/ZnUrl-Constructing-without-Scheme-tp4811576.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Sean, The scheme is not optional, it defines what (kind) the URL is. You are expecting behaviour such as in a browser's address bar. But there, there is context (you are expecting an HTTP URL). What you are looking for is provided: ZnUrl fromString: 'www.host.com' defaultScheme: #http Are you reading the specs differently ? Sven
On 12 Mar 2015, at 21:21, Sean P. DeNigris <sean@clipperadams.com> wrote:
'http://www.hm.com' asUrl host = 'www.hm.com'. All good so far, but: 'www.hm.com' asUrl host = nil. 'www.hm.com' asUrl segments = an OrderedCollection('www.hm.com')
I realize presenting a URL without a scheme is kind of vague, but the least surprising thing to me would be to interpret schemeless URLs as starting with the authority. After all, most people commonly use "www.hm.com" as a shorthand for "http://www.hm.com"
----- Cheers, Sean -- View this message in context: http://forum.world.st/ZnUrl-Constructing-without-Scheme-tp4811576.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On Mar 12, 2015, at 4:54 PM, Sven Van Caekenberghe-2 [via Smalltalk] <ml-node+s1294792n4811582h30@n4.nabble.com> wrote:
The scheme is not optional, it defines what (kind) the URL is. You are expecting behaviour such as in a browser's address bar. But there, there is context (you are expecting an HTTP URL).
I did see the defaultScheme: variant. Iâm not saying we should necessarily assume HTTP. Iâm just saying if someone gives us a string like 'www.hm.comâ (which I agree is incompletely defined), why set #segments and not #host? Even with scheme = nil, the following would be more useful: 'www.hm.com' asUrl host = 'www.hm.com'. 'www.hm.com' asUrl segments = m') an OrderedCollection() ----- Cheers, Sean -- View this message in context: http://forum.world.st/ZnUrl-Constructing-without-Scheme-tp4811576p4811589.ht... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Because the scheme defines the semantics of what comes after it. Not every URL has a host, like mailto:john@acme.com (to pick an extreme case). Right now, 'foo' on itself becomes a part of the path, not the host. See also #testReferenceResolution where you can clearly see that when there is no scheme, 'g' is always seen as a path (and these examples come from an RFC). I think that what we have now is correct. I am willing to change my mind when you point to some RFC that supports your point ;-)
On 12 Mar 2015, at 22:20, Sean P. DeNigris <sean@clipperadams.com> wrote:
On Mar 12, 2015, at 4:54 PM, Sven Van Caekenberghe-2 [via Smalltalk] <[hidden email]> wrote:
The scheme is not optional, it defines what (kind) the URL is. You are expecting behaviour such as in a browser's address bar. But there, there is context (you are expecting an HTTP URL).
I did see the defaultScheme: variant. Iâm not saying we should necessarily assume HTTP. Iâm just saying if someone gives us a string like 'www.hm.comâ (which I agree is incompletely defined), why set #segments and not #host? Even with scheme = nil, the following would be more useful: 'www.hm.com' asUrl host = 'www.hm.com'. 'www.hm.com' asUrl segments = m') an OrderedCollection() Cheers, Sean
View this message in context: Re: ZnUrl: Constructing without Scheme Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On Mar 12, 2015, at 5:30 PM, Sven Van Caekenberghe-2 [via Smalltalk] <ml-node+s1294792n4811591h9@n4.nabble.com> wrote:
I think that what we have now is correct. I am willing to change my mind when you point to some RFC that supports your point ;-) Well in that caseâ¦
^ Response new emoticon: ':-Pâ; sound: Sound raspberry; yourself. ----- Cheers, Sean -- View this message in context: http://forum.world.st/ZnUrl-Constructing-without-Scheme-tp4811576p4811593.ht... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Sean,
On 12 Mar 2015, at 22:33, Sean P. DeNigris <sean@clipperadams.com> wrote:
On Mar 12, 2015, at 5:30 PM, Sven Van Caekenberghe-2 [via Smalltalk] <[hidden email]> wrote:
I think that what we have now is correct. I am willing to change my mind when you point to some RFC that supports your point ;-) Well in that caseâ¦
^ Response new emoticon: ':-Pâ; sound: Sound raspberry; yourself. Cheers, Sean
View this message in context: Re: ZnUrl: Constructing without Scheme Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
I do not entirely understand, but anyway, I just committed this: === Name: Zinc-Resource-Meta-Tests-SvenVanCaekenberghe.33 Author: SvenVanCaekenberghe Time: 13 March 2015, 4:38:39.625508 pm UUID: dbf5fd62-d9b2-48be-a1bb-cd22dec62852 Ancestors: Zinc-Resource-Meta-Tests-SvenVanCaekenberghe.32 Replace ZnUrlTests>>#testMissingScheme by the more extensive ZnUrlTests>>#testNoScheme - an attempt to make it more explicit using external test code why, when there is no scheme, there is no host:port interpretation, but instead the input is seen a a path Add ZnUrlTests>>#testDefaultPortUnknownScheme === Maybe this makes it easier to understand why things are the way they are. ZnUrlTests>>#testNoScheme "When there is no scheme, there is no host:port interpretation, but instead the input is seen a a path - externalize this in test code" #('foo' 'localhost' 'www.foo.com' 'foo.txt' 'foo:1') do: [ :input | | url | url := input asZnUrl. self deny: url hasScheme. self deny: url hasHost. self deny: url hasPort. self deny: url hasQuery. self deny: url hasFragment. self assert: url hasPath. self assert: url isFilePath. self assert: url firstPathSegment equals: input ]. #('/dir/foo.txt' 'dir/foo.txt') do: [ :input | | url | url := input asZnUrl. self deny: url hasScheme. self deny: url hasHost. self deny: url hasPort. self deny: url hasQuery. self deny: url hasFragment. self assert: url hasPath. self assert: url isFilePath. self assert: url pathSegments equals: #('dir' 'foo.txt') asOrderedCollection ] I think this is correct. The alternative, what you are suggesting, would make most if not all of the above be interpreted as hosts. Sven
Am 12.03.2015 um 22:20 schrieb Sean P. DeNigris <sean@clipperadams.com>:
On Mar 12, 2015, at 4:54 PM, Sven Van Caekenberghe-2 [via Smalltalk] <[hidden email] <x-msg://25/user/SendEmail.jtp?type=node&node=4811589&i=0>> wrote:
The scheme is not optional, it defines what (kind) the URL is. You are expecting behaviour such as in a browser's address bar. But there, there is context (you are expecting an HTTP URL).
I did see the defaultScheme: variant. Iâm not saying we should necessarily assume HTTP. Iâm just saying if someone gives us a string like 'www.hm.com <http://www.hm.com/>â (which I agree is incompletely defined), why set #segments and not #host? Even with scheme = nil, the following would be more useful: 'www.hm.com <http://www.hm.com/>' asUrl host = 'www.hm.com <http://www.hm.com/>'. 'www.hm.com <http://www.hm.com/>' asUrl segments = m <http://www.hm.com/>') an OrderedCollection()
To me it is a discussion what is the real interpretation of ZnUrl. It behaves mostly like URI but the name implies URL. Without a colon you are in URI land. It is just a path. Starting with /, // or without slash determines the kind of path. So www.hm.com <http://www.hm.com/> ist perfectly valid path. Just create a file named www.hm.com <http://www.hm.com/> on your filesystem and you can luckily reference it with that URI. Having a URI/URL object in mind there is nothing to assume. From a text block point of view that might be different. Text display in apps use something like linkify. There you scan the content for patterns like www.*.* or even *.*.* (matching domains for the last part) and if you find some you assume it to be a URL with the host you've found. But then you create the URLs out of that given context. Maybe you need another selector like asHttpUrl? My concern is more that 'urn:foo:bar' asUrl doesn't do what it should :) Norbert
On 13 Mar 2015, at 17:20, Norbert Hartl <norbert@hartl.name> wrote:
My concern is more that
'urn:foo:bar' asUrl
doesn't do what it should :)
That is because #urn is not in #schemesNotUsingDoubleSlash, it should probably be added. But then I have to read more about it first. https://en.wikipedia.org/wiki/Uniform_resource_name
Am 13.03.2015 um 17:29 schrieb Sven Van Caekenberghe <sven@stfx.eu>:
On 13 Mar 2015, at 17:20, Norbert Hartl <norbert@hartl.name> wrote:
My concern is more that
'urn:foo:bar' asUrl
doesn't do what it should :)
That is because #urn is not in #schemesNotUsingDoubleSlash, it should probably be added.
But then I have to read more about it first.
I need to dig into it, too. I just wondered why 'abc' asUrl prints '/abc' That doesn't appear right. What do you think? It is just a URI path or a relative URL (depending how you like to put it). A relative URL resolved by a base URI will work because 'http://foo.com/foo//abc' <http://foo.com/foo//abc'> (<â double slash) is still valid. I think that scheme is supposed to be a class and the parsing of the remaining string is delegated to that scheme. That would make it more easy to have URL (the locator part) as specialization to plain URI. But then it will make the code base a lot more complex and performance wise it probably has its cost. But then there would be a scheme registry that can easily extended by custom schemes. Just some quick thoughts, Norbert
I know you mean well, but you cannot confuse things. Without some context, not much can be done. #asZnUrl has totally no context. I recently added ZnUrl>>#withRelativeReference: reference "Return a new URL by parsing & resolving the relative reference using myself as base URL. This implements the process described in RFC 3986 Section 5" See also #testReferenceResolution The specs (RFCs) do count, the rest is often wishful thinking that does not take all use cases into account. Of course, ZnUrl is not the final answer to this broad problem, just some answer that started in the HTTP world. I don't want to change its parsing unless there is a very clear reason and explanation why/how.
On 13 Mar 2015, at 19:18, Norbert Hartl <norbert@hartl.name> wrote:
Am 13.03.2015 um 17:29 schrieb Sven Van Caekenberghe <sven@stfx.eu>:
On 13 Mar 2015, at 17:20, Norbert Hartl <norbert@hartl.name> wrote:
My concern is more that
'urn:foo:bar' asUrl
doesn't do what it should :)
That is because #urn is not in #schemesNotUsingDoubleSlash, it should probably be added.
But then I have to read more about it first.
I need to dig into it, too. I just wondered why
'abc' asUrl
prints '/abc'
That doesn't appear right. What do you think? It is just a URI path or a relative URL (depending how you like to put it). A relative URL resolved by a base URI will work because 'http://foo.com/foo//abc' (<â double slash) is still valid.
I think that scheme is supposed to be a class and the parsing of the remaining string is delegated to that scheme. That would make it more easy to have URL (the locator part) as specialization to plain URI. But then it will make the code base a lot more complex and performance wise it probably has its cost. But then there would be a scheme registry that can easily extended by custom schemes.
Just some quick thoughts,
Norbert
Am 13.03.2015 um 20:04 schrieb Sven Van Caekenberghe <sven@stfx.eu>:
I know you mean well, but you cannot confuse things. Without some context, not much can be done. #asZnUrl has totally no context.
Maybe this is misunderstanding. My point was that there is no context given by #asUrl. So it is not a locator at all therefor the leading slash is confusing to me.
I recently added ZnUrl>>#withRelativeReference: reference "Return a new URL by parsing & resolving the relative reference using myself as base URL. This implements the process described in RFC 3986 Section 5"
See also #testReferenceResolution
The specs (RFCs) do count, the rest is often wishful thinking that does not take all use cases into account.
Agreed, I'll consult the specs again.
Of course, ZnUrl is not the final answer to this broad problem, just some answer that started in the HTTP world.
I don't want to change its parsing unless there is a very clear reason and explanation why/how.
I didn't want to complain. Your stuff is pretty awesome and there should be really good reasons to change it. History just introduced the ambiguity between URL and URl. An URI is just an identifier. A scheme puts additional meaning on how to interpret stuff. Sorry if I confused anything. Norbert
On 13 Mar 2015, at 19:18, Norbert Hartl <norbert@hartl.name> wrote:
Am 13.03.2015 um 17:29 schrieb Sven Van Caekenberghe <sven@stfx.eu>:
On 13 Mar 2015, at 17:20, Norbert Hartl <norbert@hartl.name> wrote:
My concern is more that
'urn:foo:bar' asUrl
doesn't do what it should :)
That is because #urn is not in #schemesNotUsingDoubleSlash, it should probably be added.
But then I have to read more about it first.
I need to dig into it, too. I just wondered why
'abc' asUrl
prints '/abc'
That doesn't appear right. What do you think? It is just a URI path or a relative URL (depending how you like to put it). A relative URL resolved by a base URI will work because 'http://foo.com/foo//abc' (<â double slash) is still valid.
I think that scheme is supposed to be a class and the parsing of the remaining string is delegated to that scheme. That would make it more easy to have URL (the locator part) as specialization to plain URI. But then it will make the code base a lot more complex and performance wise it probably has its cost. But then there would be a scheme registry that can easily extended by custom schemes.
Just some quick thoughts,
Norbert
participants (3)
-
Norbert Hartl -
Sean P. DeNigris -
Sven Van Caekenberghe