URL Explained – The Fundamentals(ittavern.com)
ittavern.com
URL Explained – The Fundamentals
https://ittavern.com/url-explained-the-fundamentals/
19 comments
Hello, author here: thank you for your feedback!
In general, I've removed the notes in the brackets and either added more context and examples or integrated it into the text.
> Scheme: (always present, not always visible)
Added more context.
> Path: (always present)
You are right, the root directory `/` is implied. Added this as an example.
> It is recommended to place IPv4 and IPv6 addresses into brackets:
Correct, my bad. I've added more examples and the note, that it is required to put IPv6 addresses into square brackets.
> Host: (always present, not always visible)
Been a while so I am not sure what I meant. I've made some changes and added more examples.
Again, thank you!
In general, I've removed the notes in the brackets and either added more context and examples or integrated it into the text.
> Scheme: (always present, not always visible)
Added more context.
> Path: (always present)
You are right, the root directory `/` is implied. Added this as an example.
> It is recommended to place IPv4 and IPv6 addresses into brackets:
Correct, my bad. I've added more examples and the note, that it is required to put IPv6 addresses into square brackets.
> Host: (always present, not always visible)
Been a while so I am not sure what I meant. I've made some changes and added more examples.
Again, thank you!
maybe it just meant that the scheme isn't visible in the address bar in a browser like chrome.
Author here; you are right! - Added more context. Thank you
Ah, … interesting.
Firefox doesn't do such silliness.
Firefox doesn't do such silliness.
> Host: (always present, not always visible)
Hostname can be skipped in file URI and localhost will be assumed, maybe that's what the author meant.
Hostname can be skipped in file URI and localhost will be assumed, maybe that's what the author meant.
Ho! You're right, that is a corner case. It has the netloc's starting sigil ("//") but there's nothing prior the path.
I was just uncertain enough on that one that I didn't want to say it never happens, and I'm kinda glad I didn't.
I was just uncertain enough on that one that I didn't want to say it never happens, and I'm kinda glad I didn't.
I've pointed many, many, new hires at the URL Wikipedia page.
https://en.m.wikipedia.org/wiki/URL
https://en.m.wikipedia.org/wiki/URL
Fragment identifiers are not sent to the server.
query example should have both ? and & like
Also, the story on the www "subdomain" is missing.
query example should have both ? and & like
?foo=1&bar=2&baz=3
Also, the story on the www "subdomain" is missing.
The a=b&c=d syntax is part of application/x-www-url-formencoded which was a Mosaic invention, and came after query strings. [0] [1]
[0] http://1997.webhistory.org/www.lists/www-talk.1993q3/0812.ht...
[1] https://web.archive.org/web/19961220100435/http://www.ncsa.u...
[0] http://1997.webhistory.org/www.lists/www-talk.1993q3/0812.ht...
[1] https://web.archive.org/web/19961220100435/http://www.ncsa.u...
Hello, author here, thank you for your feedback.
> Fragment identifiers are not sent to the server.
I've not stated that this is the case, but I might add a note, that this is the case.
> query example should have both ? and & like > ?foo=1&bar=2&baz=3
The `&` is only needed if you have multiple parameters like in the Youtube example, or am I getting it wrong?
> Perhaps behind the path/to/whatever have a /filename.XXX
This is an example for a path without explicit resource as most servers would provide an `index.html` file by default in this case. I might add a note to clarify it.
> Also, the story on the www "subdomain" is missing.
Story, as in history?
> Fragment identifiers are not sent to the server.
I've not stated that this is the case, but I might add a note, that this is the case.
> query example should have both ? and & like > ?foo=1&bar=2&baz=3
The `&` is only needed if you have multiple parameters like in the Youtube example, or am I getting it wrong?
> Perhaps behind the path/to/whatever have a /filename.XXX
This is an example for a path without explicit resource as most servers would provide an `index.html` file by default in this case. I might add a note to clarify it.
> Also, the story on the www "subdomain" is missing.
Story, as in history?
The page is wonderful as is but nothing is ever perfect. I think the page has 3 different readers: 1) quickly figure out how url's work (without the useless username:password@ and the port number) 2) The full spec/technical description. 3) The elaborate: Everything there is to know about this, history use cases etc.
I remember when it was normal to have data structures separated by whatever character. Sometimes you needed multiple or (heaven forbid) more than one character. It wasn't always as pretty as one would like. The URL is the worse case with all this "://",":", ".", "@", "/", "?", "&", "#" which may have a different meaning depending on where they are found. It is now complex enough to challenge even the best of us.
I keep making this joke no one thinks is funny: how embarrassing it is to have to explain this to the youngsters. We can only hope they are naive enough not to loudly protest our compound mistakes.
Imagine how the reader is assumed to know the "[notation]" for optional parts but then "we" chose to wrap the ipv6 in it! Or take how it isn't mailto:// nor https:www.example.com
I'm not entirely sure but I think it was www as opposed to ftp.example.com or mail, smpt, pop? The www was the new thing on the internet.
> I've not stated that this is the case, but I might add a note, that this is the case.
It is never mentioned on pages like yours but seems interesting perhaps even useful to know.
> The `&` is only needed if you have multiple parameters
What samtho wrote below is interesting. Apparently it is just convention. You can do whatever you like (as long as it doesn't include a "#" I presume)
You could say:
scheme://username:password@hostname:port/path?query#fragment
But then it would be less obvious than something like:
http ://jack:[email protected]:80/vacation/antartica/temprature.php?year=1988&month=march#notes
Except the username:password and the port people are likely to have seen most parts browsing the web.
I remember when it was normal to have data structures separated by whatever character. Sometimes you needed multiple or (heaven forbid) more than one character. It wasn't always as pretty as one would like. The URL is the worse case with all this "://",":", ".", "@", "/", "?", "&", "#" which may have a different meaning depending on where they are found. It is now complex enough to challenge even the best of us.
I keep making this joke no one thinks is funny: how embarrassing it is to have to explain this to the youngsters. We can only hope they are naive enough not to loudly protest our compound mistakes.
Imagine how the reader is assumed to know the "[notation]" for optional parts but then "we" chose to wrap the ipv6 in it! Or take how it isn't mailto:// nor https:www.example.com
I'm not entirely sure but I think it was www as opposed to ftp.example.com or mail, smpt, pop? The www was the new thing on the internet.
> I've not stated that this is the case, but I might add a note, that this is the case.
It is never mentioned on pages like yours but seems interesting perhaps even useful to know.
> The `&` is only needed if you have multiple parameters
What samtho wrote below is interesting. Apparently it is just convention. You can do whatever you like (as long as it doesn't include a "#" I presume)
You could say:
scheme://username:password@hostname:port/path?query#fragment
But then it would be less obvious than something like:
http ://jack:[email protected]:80/vacation/antartica/temprature.php?year=1988&month=march#notes
Except the username:password and the port people are likely to have seen most parts browsing the web.
For the query portion, it really depends if your are reading it server side or client side and using the WHATWG standard[0] which itself just mirrors convention. However, the standard dictating how a URL might be formed does not mandate anything about the query string that makes it parsable.
[0]: https://url.spec.whatwg.org/#interface-urlsearchparams
[0]: https://url.spec.whatwg.org/#interface-urlsearchparams
Also, what's with ";" as a delimiter in the query? I would've appreciated an example
> It is recommended to place IPv4 and IPv6 addresses into brackets:
I tried doing this, and my brower(s) just assumed it was a search string, and took me to my search engine. Does that mean they're not following the RFC? (section 3.2.2 of RFC3896) Should I file a bug with Mozilla?
I tried doing this, and my brower(s) just assumed it was a search string, and took me to my search engine. Does that mean they're not following the RFC? (section 3.2.2 of RFC3896) Should I file a bug with Mozilla?
The post is incorrect, only IPv6 addresses are meant to be put in brackets.
And in that case, the square brackets are not only recommended; they are required.
Author here; you guys are right! - I've corrected it. Thank you
You are correct, reading the RFC just a little further than my ctrl+f found:
> A host identified by an Internet Protocol literal address, version 6 [RFC3513] or later, is distinguished by enclosing the IP literal within square brackets ("[" and "]").
> A host identified by an Internet Protocol literal address, version 6 [RFC3513] or later, is distinguished by enclosing the IP literal within square brackets ("[" and "]").
> Scheme: (always present, not always visible)
Schemes are required by the URI/URL's grammar. I'm not entirely sure what "always present, not always visible" even means … those would seem to be synonyms. Perhaps we could infer "not always visible" to mean that there's some implied default … but there's not, not for a URI/URL. (For a relative-ref, yes.)
> Path: (always present)
… but this blows our implied default theory above out of the water. Paths are not always present: "https://google.com" is a valid URL, with no path. (One could say it implies "/", but … see the above.)
> It is recommended to place IPv4 and IPv6 addresses into brackets:
It is definitely not "recommended" … it's malformed to put IPv4 addresses in brackets, and it's mandatory for IPv6 addresses.
Just read the RFC? https://datatracker.ietf.org/doc/html/rfc3986
> Host: (always present, not always visible)
I'm trying to think of how you could have a URL without a host "visible". The network location is like the defining feature of a URL, vs. a URI.
But if a URI lacks a host, it's not just "not visible", again, there's no implied default there. "Host" might not even make sense, depending on the scheme.