6 ms·

For http:com/example/foo/bar/baz how would you determine what the host is?

by echeese 10y ago

zackbloom 10y ago
He, unfortunately, didn't disambiguate between example.com/foo/bar/baz, foo.example.com/bar/baz, etc. so it's unclear. It is kind of amusing to think of the entire Internet as a giant directory though.
- thaumasiotes 10y ago
  > It is kind of amusing to think of the entire Internet as a giant directory though. How else would you think about it?
  - krapp 10y ago
    A distributed operating system, with the URL being a shell command sent to some remote application. The resemblance between a URL and a directory path is becoming an anachronism anyway, as: GET http://example.com/foo/bar/baz might as well be return com.example.foo(bar, baz) more often then than not.
    - thaumasiotes 10y ago
      I don't understand the distinction you're trying to draw. On a personal machine, a directory path might look like /usr/bin/vi whereas a command would look like /usr/bin/vi. Command invocations require you to identify what command you want. So we provide locations.
      - krapp 10y ago
        My point is that a URL is often an abstraction of an invocation of a function or class with segments and query parameters mapping to methods or arguments, and that it doesn't need to have any relationship to file paths on the server, despite superficially looking like a file path.
    - jacquesm 10y ago
      > A distributed operating system, with the URL being a shell command sent to some remote application. All too often URLs really do allow you to issue shell commands (or raw SQL), even today!
wtbob 10y ago
It doesn't actually matter: in a world which used that sort of addressing, one could imagine saying to com 'give me HTTP info for your example/foo/bar/baz,' to com/example 'give me HTTP info for your foo/bar/baz' and so forth; in that case, com would just say, 'hey, go talk to 266.328.0.1 (that's what I call example)' and 266.328.0.1 would cheerfully return the information stored at the filesystem path /foo/bar/baz, or it could say, 'hey, I call foo 463.622.42.17' and your browser would keep resolving. Me, I kinda wish we wrote URLs as http://com.example.host.invalid/path/to/resource http://com.example.host.invalid/path/to/resource.
- zackbloom 10y ago
  That's very interesting! Removing the separation between DNS resolving hosts and applications resolving paths. All paths could be resolved by a hierarchical DNS-like system which you also ran inside your service to route requests to subfolders. Cool.
- gumby 10y ago
  > Me, I kinda wish we wrote URLs as http://com.example.host.invalid/path/to/resource http://com.example.host.invalid/path/to/resource. The UK's predecessor to the DNS worked this way (a "big endian" hierarchy). Sorry I can't remember the network name; if I remember it was rooted in gb.
  - cbd1984 10y ago
    JANET, which routed email to Czechoslovakia, as the legend goes... Back then mainly the Computer Science departments had email, so they'd have domain names beginning with a cs. in the ARPA scheme, but, since JANET did it backwards, you'd have to rearrange the domain name so it ended with a .cs for that network. If you did that and didn't reverse it back, the domain name would have a ccTLD of .cs, which is what Czechoslovakia used. (The .cs ccTLD existed until 1995, years after Czechoslovakia ceased to. The .su ccTLD (Soviet Union) still exists.)
  - Theodores 10y ago
    I am old enough to remember the final year of JANET with the backwards addresses. At the time I was at Plymouth Marine Laboratory with a university email address of the type researcher@uk.ac.pml - i.e. backwards. However, in those days there were many different things about networks, you could have several connector types in a room so anything beyond email was a bit like the difference between travelling across state borders in the U.S. and travelling across the Iron Curtain. I can't remember how one got from one's VT terminal to the wider internet on VAX/VMS but that was possible. FTP and some Telnet was how it worked, none of this www stuff. The change of address structure to normal internet style was not that big of a change, you would think it would have been as traumatic as changing what side of the road to drive on or the Millennium Bug, but, the change happened with no huge amount of work needed or resultant disruption.
inopinatus 10y ago
Fun fact: nowhere in the HTTP protocol specification does it say "use DNS". It is a convention that we do. It is a further convention that we use A records. And in my opinion it was a travesty that HTTP/2 did not mandate using DNS with SRV records.
- wahern 10y ago
  Corporate firewalls have ruined the internet. You can't put a website on an arbitrary port. The shift to SSL won't even change that, because sysadmins and similar professionals like categorizing traffic by port, and no amount of reasoning will change that. They still think you can filter good/bad, allowed/disallowed by port, even if you can't scan it. Load-balancing isn't within the ambit of HTTP, so that doesn't weigh in favor of SRV. The _service._proto template for SRV names is pointless for anything already communicating over HTTP, as it's going to be either too specific/redundant or not specific enough for your particular scenario. For example, I'm using SRV for a automatic service registration and discovery project and ignoring it entirely. But ignoring that in a standard is awkward. Finally, IPv6 (presuming we get there!) will make ports redundant. You can just assign a new address to your service. The historical baggage will be annoying (requiring root to bind to ports <1024), but with VMs and containers corporate software doesn't bother with old-school best practices like that. And we're ignoring that there's already an installed base and market for load balancers, redirectors, etc. I understand that the dream is to be able to move that logic back toward the edges, and I whole heartedly agree. But as with filtering by port number, the majority of IT professionals just don't think that way.
  - inopinatus 10y ago
    We achieve change incrementally. If you think corporate firewalls and inflexible admins should define the architecture of the internet, you have already lost. In practice, they adapt. Believe me they are already having to, with the change of wire format and connection behaviours due to HTTP/2 requests. Actually nothing persuades a stick-in-the-mud sysadmin quite like a ratified standards document: that is something they can relate to. I say this with confidence because I am a stick-in-the-mud sysadmin. The major immediate utility of SRV records is one we haven't mentioned: they can be aliases at apex records, because they are not A/AAAA records. The broader case is that all protocols should be using SRV because overloading address records for service discovery has so many misbehaviours. Allocating multiple IPv6 addresses doesn't fix the problem of overloaded symbolic names. Using address records hurts the adoption of DNS for federation.

For http:com/example/foo/bar/baz how would you determine what the host is?

by echeese 10y ago

For http:com/example/foo/bar/baz how would you determine what the host is?

He, unfortunately, didn't disambiguate between example.com/foo/bar/baz, foo.example.com/bar/baz, etc. so it's unclear. It is kind of amusing to think of the entire Internet as a giant directory though.

thaumasiotes 10y ago
> It is kind of amusing to think of the entire Internet as a giant directory though. How else would you think about it?
- krapp 10y ago
  A distributed operating system, with the URL being a shell command sent to some remote application. The resemblance between a URL and a directory path is becoming an anachronism anyway, as: GET http://example.com/foo/bar/baz might as well be return com.example.foo(bar, baz) more often then than not.
  - thaumasiotes 10y ago
    I don't understand the distinction you're trying to draw. On a personal machine, a directory path might look like /usr/bin/vi whereas a command would look like /usr/bin/vi. Command invocations require you to identify what command you want. So we provide locations.
    - krapp 10y ago
      My point is that a URL is often an abstraction of an invocation of a function or class with segments and query parameters mapping to methods or arguments, and that it doesn't need to have any relationship to file paths on the server, despite superficially looking like a file path.
  - jacquesm 10y ago
    > A distributed operating system, with the URL being a shell command sent to some remote application. All too often URLs really do allow you to issue shell commands (or raw SQL), even today!

wtbob 10y ago

It doesn't actually matter: in a world which used that sort of addressing, one could imagine saying to com 'give me HTTP info for your example/foo/bar/baz,' to com/example 'give me HTTP info for your foo/bar/baz' and so forth; in that case, com would just say, 'hey, go talk to 266.328.0.1 (that's what I call example)' and 266.328.0.1 would cheerfully return the information stored at the filesystem path /foo/bar/baz, or it could say, 'hey, I call foo 463.622.42.17' and your browser would keep resolving. Me, I kinda wish we wrote URLs as http://com.example.host.invalid/path/to/resource http://com.example.host.invalid/path/to/resource.

zackbloom 10y ago
That's very interesting! Removing the separation between DNS resolving hosts and applications resolving paths. All paths could be resolved by a hierarchical DNS-like system which you also ran inside your service to route requests to subfolders. Cool.
gumby 10y ago
> Me, I kinda wish we wrote URLs as http://com.example.host.invalid/path/to/resource http://com.example.host.invalid/path/to/resource. The UK's predecessor to the DNS worked this way (a "big endian" hierarchy). Sorry I can't remember the network name; if I remember it was rooted in gb.
- cbd1984 10y ago
  JANET, which routed email to Czechoslovakia, as the legend goes... Back then mainly the Computer Science departments had email, so they'd have domain names beginning with a cs. in the ARPA scheme, but, since JANET did it backwards, you'd have to rearrange the domain name so it ended with a .cs for that network. If you did that and didn't reverse it back, the domain name would have a ccTLD of .cs, which is what Czechoslovakia used. (The .cs ccTLD existed until 1995, years after Czechoslovakia ceased to. The .su ccTLD (Soviet Union) still exists.)
- Theodores 10y ago
  I am old enough to remember the final year of JANET with the backwards addresses. At the time I was at Plymouth Marine Laboratory with a university email address of the type researcher@uk.ac.pml - i.e. backwards. However, in those days there were many different things about networks, you could have several connector types in a room so anything beyond email was a bit like the difference between travelling across state borders in the U.S. and travelling across the Iron Curtain. I can't remember how one got from one's VT terminal to the wider internet on VAX/VMS but that was possible. FTP and some Telnet was how it worked, none of this www stuff. The change of address structure to normal internet style was not that big of a change, you would think it would have been as traumatic as changing what side of the road to drive on or the Millennium Bug, but, the change happened with no huge amount of work needed or resultant disruption.

inopinatus 10y ago

Fun fact: nowhere in the HTTP protocol specification does it say "use DNS". It is a convention that we do. It is a further convention that we use A records. And in my opinion it was a travesty that HTTP/2 did not mandate using DNS with SRV records.

wahern 10y ago
Corporate firewalls have ruined the internet. You can't put a website on an arbitrary port. The shift to SSL won't even change that, because sysadmins and similar professionals like categorizing traffic by port, and no amount of reasoning will change that. They still think you can filter good/bad, allowed/disallowed by port, even if you can't scan it. Load-balancing isn't within the ambit of HTTP, so that doesn't weigh in favor of SRV. The _service._proto template for SRV names is pointless for anything already communicating over HTTP, as it's going to be either too specific/redundant or not specific enough for your particular scenario. For example, I'm using SRV for a automatic service registration and discovery project and ignoring it entirely. But ignoring that in a standard is awkward. Finally, IPv6 (presuming we get there!) will make ports redundant. You can just assign a new address to your service. The historical baggage will be annoying (requiring root to bind to ports <1024), but with VMs and containers corporate software doesn't bother with old-school best practices like that. And we're ignoring that there's already an installed base and market for load balancers, redirectors, etc. I understand that the dream is to be able to move that logic back toward the edges, and I whole heartedly agree. But as with filtering by port number, the majority of IT professionals just don't think that way.
- inopinatus 10y ago
  We achieve change incrementally. If you think corporate firewalls and inflexible admins should define the architecture of the internet, you have already lost. In practice, they adapt. Believe me they are already having to, with the change of wire format and connection behaviours due to HTTP/2 requests. Actually nothing persuades a stick-in-the-mud sysadmin quite like a ratified standards document: that is something they can relate to. I say this with confidence because I am a stick-in-the-mud sysadmin. The major immediate utility of SRV records is one we haven't mentioned: they can be aliases at apex records, because they are not A/AAAA records. The broader case is that all protocols should be using SRV because overloading address records for service discovery has so many misbehaviours. Allocating multiple IPv6 addresses doesn't fix the problem of overloaded symbolic names. Using address records hurts the adoption of DNS for federation.