Actually, if you check Archive.org [0], choose "urls" in menu, then sort by url in reverse order, you will get resources with https dated 1996. So I'd say it's at least plausible.
I remember always having to go java.sun.com (rather than java.com or Sun's java landing page which was the first search result) as the quickest way for a no-BS JDK download, and it seems at least Oracle still has that URL redirect to a JDK download listing.
At the same time, you're giving free feedback saying that his free comment is a poor comment.
Arguably, his poor comment may have taken less effort than the poor video he was criticizing, and probably an equivalent effort to your comment on his comment... anyway, this doesn't seem to stop... until this will look like Reddit.
Yep, webdesign peaked around that 2008. Since then, it's all downhill. I blame Apple for inventing smarphones with a capable web browser included, for causing this.
I re-watched the iPhone keynote a while ago. One of the key features was that you could browse the web and get the full desktop experience, instead of functionally crippled mobile versions of websites. That went well...
I started reading the first snapshot they had (1996), and noticed that there was once a web browser called Grail which aimed to be a web browser completely written in Python: https://arquivo.pt/wayback/19961013225840/http://monty.cnri.... Very neat stuff. Almost 30 years later, I bet someone would have enjoyed that. (If it had taken off, we might be scripting web pages in Python instead of Javascript, even!)
They quit working on it when it was realized that stopping arbitrary code execution via escalation from isolated code execution was practically impossible to stop in the interpreter.
If you put in a blocked site [1], interestingly a picture of j robert oppenheimer comes up telling you that this is a service from los alamos national laboratory.
Shame they blocked deoxy, that was one of the oldest websites on the internet. They even had a version from the early 90s which was meant to be browsed in a text-based browser.
All these links are prefixed with https://href.li which uses meta refresh as a means of redirection, which apparently still works on most popular browsers, to "hide" the Referer header. What I have never understood is why no one cares if the operator of href.li thereby gets logs of every URL submitted along with originating IP. In this example, there is an implicit assumption that the user wishes to "hide" the Referer header from one website, e.g., arquivo.pt, archive.org, bibalex.org, vefsafn.is, loc.gov, webcitation.org, or archive-it.org, but not from another, i.e., href.li.^1 This is, IMO, a recurring theme with "free web-based service"^2 websites and "tech" companies. One website/"tech" company expects users to trust it but to distrust others.^3 Nevermind that the choice might sometimes be between the lesser of two/multiple evils, so to speak.
1. Though I suspect here it is the operator of mementoweb.org who has the interest in hiding the Referer header, for whatever reason.
2. The easiest way to avoid the annoyances of Referer headers is not to send them. Unless things have changed, sending a Referer header can be disabled in Firefox. A local forward proxy can also remove the Referer header. Smaller, open source HTTP clients that users can fully control and modify need not send Referer headers. With possible rare exceptions, only ever raised by website operators and "tech" employees, sending the Referer header serves no benefit to users. It should be optional, but the most popular browsers remove that choice.
3. Google is an obvious example. DuckDuckGo and other alternative search engines have also been known to prefix URLs to create redirects, purportedly to "protect" users form the dangers of the Referer header. This of course also allows the search engine to track every URL (search result) that a user "clicks".
42 comments
[ 2.1 ms ] story [ 86.9 ms ] threadNot sure why the HN title is editorialized to add an emphasized HTTPS, weird.
Edit: HN fixed the title
[0] https://web.archive.org/web/*/https://www.python.org*
http://web.archive.org/web/19981201210443/https://www.info.c...
Neither the protocol nor the "www" subdomain are "right", yet archive.org serves some snapshot.
The change I'd make is to add a big-ass "Download" button somewhere. That has to be the number one reason why people visit python.org, after all.
Arguably, his poor comment may have taken less effort than the poor video he was criticizing, and probably an equivalent effort to your comment on his comment... anyway, this doesn't seem to stop... until this will look like Reddit.
2020: A picture.
The website is actually still up: http://grail.sourceforge.net/ The latest minor release is from 1999.
It was a candidate I believe, but it's not easy to search for information on that...
Shame they blocked deoxy, that was one of the oldest websites on the internet. They even had a version from the early 90s which was meant to be browsed in a text-based browser.
[1] http://timetravel.mementoweb.org/list/20000705010912/http://...
1. Though I suspect here it is the operator of mementoweb.org who has the interest in hiding the Referer header, for whatever reason.
2. The easiest way to avoid the annoyances of Referer headers is not to send them. Unless things have changed, sending a Referer header can be disabled in Firefox. A local forward proxy can also remove the Referer header. Smaller, open source HTTP clients that users can fully control and modify need not send Referer headers. With possible rare exceptions, only ever raised by website operators and "tech" employees, sending the Referer header serves no benefit to users. It should be optional, but the most popular browsers remove that choice.
3. Google is an obvious example. DuckDuckGo and other alternative search engines have also been known to prefix URLs to create redirects, purportedly to "protect" users form the dangers of the Referer header. This of course also allows the search engine to track every URL (search result) that a user "clicks".