h a l f b a k e r yBite me.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
The great thing about HTTP/1.0 was that you could specify the IP rather than the domain name if you knew it... with HTTP/1.1 this rarely works as the Host information of the request is usually used to determine the domain to serve you (not just the IP you are accessing).
In the olden days, there were
large networks of internet homepages which could only be accessed by IP; indeed, they often had no internet domain name. This added to their prestige amongst early cyber surfers.
Today there is a similar shadow-realm; that of many sites which are hosted on servers to which the domain name does not resolve. Usually, it is caused an old host that never bothered deleting the files when the domain switched to another host. There may be other good reasons... for example, some government sites 'might' maintain whole emergency systems just waiting for a DNS switch.
Now, these secret sites are very hard to access for the ordinary searcher, and even harder for a search engine to index. Therefore, we need some of the beauty of HTTP/1.0 to be brought back into our HTTP/1.1 world. This is going to mean the ability to specify the IP address at which you want to access a given domain name.
Now, goat.se currently has an IP of 195.128.174.104, and a domain name of goat.se. Now, if aliens take over [goat.se] tomorrow and make her switch the DNS to point to an alien invasion info site, there is no easy way to access the real site any more.
My proposal is simple; brackets are not allowed in domain names; so we enable support for them as follows: http://goat.se(195.128.174.104)/
The IP address in brackets, immediately following the domain name, can then be indexed by search engines, bookmarked, or typed by ordinary internet users.
Side effect: new domain owners, for whom DNS etc. has not yet propagated, will be able to visit their brand new site, straight away, by using brackets.
Side effect 2: access to the secret realm of old copies of websites, secret security-based stuff (if you can get the IPs), and other fun stuff you never knew was online.
Note: There is the ubiquitous /etc/hosts file which I am sure you are all keen to mention. This does not help with search engines, is a lot of fuss and bother compared to HTTP/level integration, and once changed makes it hard to access another site using the same domain name (but different IP).
<<< Edited to give another major site example that does not still support HTTP/1.0 >>>
http://158.130.4.33/idea/HTTP_2f1_2e0_2e5
[hippo, Oct 29 2009]
Please log in.
If you're not logged in,
you can see what this page
looks like, but you will
not be able to add anything.
Destination URL.
E.g., https://www.coffee.com/
Description (displayed with the short name and URL.)
|
| |
Not sure I understand... Why can't you just use the IP address in the URL? (e.g. - see link) |
|
| |
I have changed the format example... (and it was just an example not something to judge the whole idea on)! The /etc/hosts file is mentioned an addressed already as Note: |
|
| |
It is now, and always was. And yes, your summary is correct. The rest is to explain the reason the background behind the idea, why idea is useful, and how it is used. |
|
| |
Why confine yourself to one IP for a site? If two servers both respond to requests for a given domain name (one being the forgotten host from years ago with a gem preserved in time), why should you not be able to access both at will? Surely this does not need to be a system level configuration, but can be as easy as typing a domain name... |
|
| |
As for search engine indexing; just the same. The content is out there, but links to it cannot be given to a search engine user... because the links would resolve to the normal IP for the user. However, if the SE can embed the IP into the link, it can specify not only which domain but which server. |
|
| |
"Why confine yourself to one IP for a site"
That's nonsensical because you're not. Multiple IPs does not imply multiple servers any more than a single IP implies a single server. |
|
| |
"If two servers both respond to requests for a given domain name..."
Then you'll get a response from whichever one receives your request first. The servers don't know about each other, nor care if they're serving up fresh content or stale. |
|
| |
If I went to Google and searched for "halfbakery" and Google returned...
halfbakery.com (123.45.67.89)
halfbakery.com (98.76.54.32)
halfbakery.com (111.222.33.44)
halfbakery.com (3.14.15.9)
...what's my cue as to which result I want? They're all the same domain name and for 99.999% of the domains out there, the content will be the same across the servers. |
|
| |
What if I type http://goat.se(1.2.3.4)/ where there's a conflict between the domain name and the IP? Which wins? Did I just poison a cache somewhere? |
|
| |
There wouldn't be a domain name lookup at all, and no cache to poison. |
|
| |
I do like the ability of specifying the host name as perceived by the receiving system, but I don't particularly see the point of indexing this any differently from any other URL. foo(1.2.3.4) is not that different from 1.2.3.4/foo - you connect to 1.2.3.4, and then you do a little extra, as interpreted by the host system. |
|
| |
Those should really be square brackets. |
|
| |
"There wouldn't be a domain name lookup at all..."
The author disagrees. |
|
| |
(Are you confusing the domain name with host headers, some sort of sub-site, or am I missing something?) |
|
| |
"The author disagrees."
I'm not sure what you mean. You can fake the desired effect by editing your /etc/hosts file and bending DNS resolves to your purpose, but that's just a workaround. |
|
| |
"Are you confusing the domain name with host headers..?"
Normally, the Host: header comes from the domain name position in the URI. (Or is inferred from a past connection.)
So, normally, the domain name and the thing in the Host header are the same. This proposal would allow them to be specified separately. |
|
| |
The idea states "Now, these secret sites are very hard to access for the ordinary searcher, and even harder for a search engine to index." In order to resolve that 'problem' the author proposes "The IP address in brackets, immediately following the domain name, can then be indexed by search engines, bookmarked, or typed by ordinary internet users." Ultimately "This is going to mean the ability to specify the IP address at which you want to access a given domain name." |
|
| |
It seems to me the author intends people to use the IP address they prefer in conjunction with what one would presume to be an appropriate domain name when typing the URL into a browser. Somehow this seeds search engines (or some other aggregator) so other people can find these "secret sites". My original reply reflects my understanding [vincevincevince]'s idea. |
|
| |
Editing the local hosts file doesn't lend the entry to be shared. It would let you emulate the idea, but only in a limited fashion. We both understand that. |
|
| |
Your understanding of foo(1.2.3.4) seems to be different than mine. I understand the author to be saying "I want to open up the web site at http://foo.com, but use IP address 1.2.3.4 to do so" with the expectation that the browser will access a copy of the Amazon web site from 1998, sitting on a disused server in a closet somewhere - forgotten, but still responding to http requests on IP 1.2.3.4. In that context foo(1.2.3.4) - or foo.com(1.2.3.4) - is very different from 1.2.3.4/foo. Ostensibly the author's usage would be foo.com/subfoo(1.2.3.4) but I could be wrong. Hell, I could be wrong about everything. |
|
| |
(For the record, I didn't really think you were confusing domain names with host headers. You seem to be interpreting the idea differently than I and I'm trying to grok both yours and the author's viewpoints) |
|
| |
There's also a bad reason for the problem this addresses: the website's domain registration expires, and someone else buys it and sets up a spammy page there instead. The annoyance of this could be reduced if there was a link from google's "cached page" feature to the site at it's old (non-spam) ip address. Anyone else who knew the correct address and had readers interested in it could link to it (either in e-mail, or from another website) |
|
| |
Possibly DNS names should be allowed in the IP section of this format, based on the reasoning below, but it does seem like a string of complications, each solving the problem of the previous one. |
|
| |
http 1.1: people host multiple differently named sites at one ip address. Address looks like http://example.com/
http 1.0.5: people can access them when the DNS system no longer refers to the desired IP: http://example.com(1.2.3.4)/ |
|
| |
Next: people who've lost their DNS name to a spammer will need portability to different IP addresses, so until they fix their site one of their users gets a DNS name to indicate what IP address they're located at: http://example.com(newip.com)/ |
|
| |