Hacker News Reader

Comment by saagarjha | Hacker News Reader

Perhaps this something that a browser should be doing, instead of websites themselves?

Enabling it by default Internet-wide seems like it could be a bad idea for many reasons. If I go out of my way to enable it on my site, I am taking responsibility for the bandwidth and any side-effects of prefetching a link and understand what I am doing. But if it is simply enabled Internet-wide, isn't that bordering on a DDoS? What about poorly-coded websites/apps where GETS are not idempotent or have side-effects? What about server-side analytics/logs tracking HTML downloads?

> What about poorly-coded websites/apps where GETS are not idempotent or have side-effects?

They're already broken, exposing that is a good thing.

Breaking the web is not a good thing. Regardless of how you think things should be done.

Indeed, breaking the web by misusing GET is not a good thing. By extension, keeping the web broken by not exposing this breakage is not a good thing either.

Like mentioned in another comment, if somebody used a GET http link to logout from a webpage, you would end up with a ton of surprised users. People who read articles by highlighting the text with the mouse would also probably hover over all of the links and would end up wasting bandwidth for no reason.

> if somebody used a GET http link to logout from a webpage,

If you violate the standards, your website doesn't work. Who knew?

> People who read articles by highlighting the text with the mouse would also probably hover over all of the links and would end up wasting bandwidth for no reason.

"For no reason" is obviously wrong, making the web snappier is a reason.

Maybe browsers should only prefetch links on bloated websites since their owners clearly don't mind wasting bandwidth.

This is just an ignorant response. The history of the internet is littered with pragmatic solutions to standard vs. non-standard approaches for exactly these reasons. See: <image>, Referer header, the HTML standard as a whole.

By the way, if your standard contradicts a popular methodology, it's probably a bad standard.

> By the way, if your standard contradicts a popular methodology, it's probably a bad standard.

You can't assume a methodology is good just because it's popular. That's how you get cargo cults.

But if a methodology violates the standards, it's almost certainly bad.

Vulnerable isn't broken

The heuristics to exclude logout links and the like would be very disruptive. Those decisions need to be in the website author's hands.

However, I think if browsers had this, but off by default until seeing tags to enable it along with any exclusions, that would be great.

It doesn't have to be. Could start by allowing website authors to opt in via a tag in the <head> or something, then opt out on a per-link basis with an attribute (eg preload=false)

I think it would only prefetch GET links, which never have side effects.

It could be a way for browsers to encourage GET to be used more correctly.

Seems like you'd be punishing users instead of website operators since the cause/effect relationship is so unobvious.

User happens to brush over the logout button while using the site. On their next click, they're logged out. Weird. Guess I'll just log in again. Doesn't happen again for some time, but then it does. Weird, didn't that happen the other week? What's wrong with my browser? Oh cool, switching browsers fixed it. You're having that issue, too? Don't worry, I figured it out. Just switch browsers.

There's nothing stopping GET requests from having side effects.

It's like pointing to a list of best practices and saying "everyone surely follows these."

For example, someone changed their signature to `[img]/logout.php[/img]` on a forum I posted on as a kid and caused chaos. The mods couldn't remove it because, on the page that lets you modify a user's signature, it shows a signature preview. Good times.

I think it was a joke as GET requests are not supposed to change anything, but often they do (probably because many devs don't know about, understand or respect the RESTful concept).

EDIT: For completeness, I have to add, that I am also part of the group of people who have violated that concept. Maybe neither frequently nor recently, but I did it too :-/

> understand or respect the RESTful concept

It's nothing to do with REST. It's part of the HTTP spec and has always been, that "GET and HEAD methods should never have the significance of taking an action other than retrieval".

Well, if I am not mistaken, REST is just the articulated concept on which HTTP was built. So yes, the HTTP spec (probably) existed before REST became a term itself, but in the end, there is no reason to argue if REST defines it or HTTP.

> There's nothing stopping GET requests from having side effects.

> It's like pointing to a list of best practices and saying "everyone surely follows these."

It’s not a ‘best practice’ it’s literally the spec for the web.

What percent of developers do you think have even read the RFC?

Browsers take a more practical approach than "well, it's in the spec, they should know better" which is apparently what you're suggesting.

It's the same reason browsers will do their best to render completely ridiculous (much less spec-complaint) HTML.

To prove your point: If I remember correctly HN votes are sent as GET.

You're typing this comment on a site that has a GET link to logout.

This phrase "GET link" I keep seeing makes sense, but strikes me as odd. Is that to differentiate from an "a" tag that triggers JS that makes a fetch/xhr with another method? The only non-JS non-GET request I'm aware of is a form action (POST by default, GET if specified) which can hardly be called a link, unless I'm wrong to equate link with "a" tag.

Form actions are actually GET by default (think search forms). You need to explicitly use <form method="post"> for a POST form.

Ah, yep.

I remember using some web accelerator 15-20 years ago. Prefetching all links on webpages. It was really helpful on modem/ISDN connection.

Standalone program on Windows XP (or maybe Windows 98?). It had it's own window where you could see which pages it was loading.

Does anyone know the name?

It's funny how much more sense this made on old-fashioned dial-up connections. Back then, as far as I remember, there was no data limit as such. The only thing that counted was connection time. Rather than sitting there reading something while generating ticks, you could better download much of the site and disconnect. An old form of rush to idle.

Doing it by default seems a bit invasive, but I'd be interested in this as a configurable option or plugin!

Reply on news.ycombinator.com