5 ms·

URL Explained – The Fundamentals

74 points by signa11 3y ago

mattpallissard 3y ago
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
codepoet80 3y ago
> 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?
- SethMLarson 3y ago
  The post is incorrect, only IPv6 addresses are meant to be put in brackets.
  - codepoet80 3y ago
    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 "]").
  - recursive 3y ago
    And in that case, the square brackets are not only recommended; they are required.
    - whatbackup 3y ago
      Author here; you guys are right! - I've corrected it. Thank you
deathanatos 3y ago
There are … a few errors in the post? > 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 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 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.
- tkot 3y ago
  > 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.
  - deathanatos 3y ago
    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.
- johnny22 3y ago
  maybe it just meant that the scheme isn't visible in the address bar in a browser like chrome.
  - whatbackup 3y ago
6510 3y ago
Fragment identifiers are not sent to the server. query example should have both ? and & like ?foo=1&bar=2&baz=3 Perhaps behind the path/to/whatever have a /filename.XXX Also, the story on the www "subdomain" is missing.
- samtho 3y ago
  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 https://url.spec.whatwg.org/#interface-urlsearchparams
- whatbackup 3y ago
  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?
  - 6510 3y ago
    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:agent007@mywebsite.com: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.

74 points by signa11 3y ago

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

codepoet80 3y ago

> 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?

SethMLarson 3y ago
The post is incorrect, only IPv6 addresses are meant to be put in brackets.
- codepoet80 3y ago
  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 "]").
- recursive 3y ago
  And in that case, the square brackets are not only recommended; they are required.
  - whatbackup 3y ago
    Author here; you guys are right! - I've corrected it. Thank you

deathanatos 3y ago

There are … a few errors in the post? > 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 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 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.

tkot 3y ago
> 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.
- deathanatos 3y ago
  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.
johnny22 3y ago
maybe it just meant that the scheme isn't visible in the address bar in a browser like chrome.
- whatbackup 3y ago

6510 3y ago

Fragment identifiers are not sent to the server. query example should have both ? and & like ?foo=1&bar=2&baz=3 Perhaps behind the path/to/whatever have a /filename.XXX Also, the story on the www "subdomain" is missing.

samtho 3y ago
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 https://url.spec.whatwg.org/#interface-urlsearchparams
whatbackup 3y ago
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?
- 6510 3y ago
  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:agent007@mywebsite.com: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.