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

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.

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.

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)