Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You know how HTTP GET requests are meant to be idempotent?

twitter.com

Post reply on HN
Print view View original

151–160 of 313 posts

Re: You know how HTTP GET requests are meant to be idempotent?

#151

Post by athenot »

beejiu wrote: post #15

When I recently added 'click to unsubscribe' functionality to my emails, the URL got wrote out into some logs. Those logs got written to a Slack channel and Slack loves to click any link it sees. Oh, and it doesn't respect robots.txt. But all I saw was every member of my list clicking 'unsubscribe'. It took a good hour to figure out exactly what was going on. Idempotence is not the problem here, by the way. That just…

I remember having a similar issue in 2000, before any (meaningful) client-side javascript. Solution: each link that did something also had a request_id parameter, which was a timestamp in milliseconds. Two requests with the same request_id meant the user had clicked something twice, so any action would NOT be performed multiple times if the same request_id came in more than once.

This let users double click on links and have the action performed only once. In 2000, hyperlinks were still confusing to some users who were used to "double-click = open", especially for file icons.

EDIT: added text in italics because initial wording was confusing.

Re: You know how HTTP GET requests are meant to be idempotent?

#152

Post by bogomipz »

zzbzq wrote: post #150

The real problem here, as usual, is web browsers, the worst class of software ever written. We constantly come across these CSRF-style bugs that are only made possible by how stupid the browser and HTTP are, but instead of blaming the culprit and trying to deal with the source, we blame ourselves for not being accommodating enough. Fool me once, shame on me, fool me 5,000 times, shame on me. Oh, and occasionally inve…

>"The real problem here, as usual, is web browsers, the worst class of software ever written."

Can you elaborate? What class of software is this specifically? And why is it the worst?

Re: You know how HTTP GET requests are meant to be idempotent?

#153

Post by YCode »

notheguyouthink wrote: post #148
beejiu wrote: post #15

When I recently added 'click to unsubscribe' functionality to my emails, the URL got wrote out into some logs. Those logs got written to a Slack channel and Slack loves to click any link it sees. Oh, and it doesn't respect robots.txt. But all I saw was every member of my list clicking 'unsubscribe'. It took a good hour to figure out exactly what was going on. Idempotence is not the problem here, by the way. That just…

> Idempotence is not the problem here, by the way. That just means calling the method twice has the same effect. But GET should have no side-effect, in an ideal world. Of course, in the case of unsubscribe links, it needs to have a side-effect to comply with the law. Thank you! I felt like I was taking crazy pills with my understanding of idempotence. Calling GET /door/open is idempotent too, but it's still gross in…

Kinda seems like he really just wanted to use the word.

Re: You know how HTTP GET requests are meant to be idempotent?

#154

Post by icebraining »

jimktrains2 wrote: post #134
elmigranto wrote: post #118

Earlier quoted context omitted.

Have a single "I clicked by mistake" button that resubscribes instead.

Yes, the automated system prefetching links will always click said button.

Not if the button issues a POST request.

Re: You know how HTTP GET requests are meant to be idempotent?

#155

Post by olavk »

zzbzq wrote: post #150

The real problem here, as usual, is web browsers, the worst class of software ever written. We constantly come across these CSRF-style bugs that are only made possible by how stupid the browser and HTTP are, but instead of blaming the culprit and trying to deal with the source, we blame ourselves for not being accommodating enough. Fool me once, shame on me, fool me 5,000 times, shame on me. Oh, and occasionally inve…

I don't see why the browser or HTTP is to blame here? GET is supposed to be safe, so what the browser is doing seem perfectly fine to me.

Re: You know how HTTP GET requests are meant to be idempotent?

#156

Post by criddell »

JimDabell wrote: post #123
criddell wrote: post #96

Earlier quoted context omitted.

Yeah - there's always a HATEOAS comment somewhere and I've never really managed to figure out what that means beyond using URI's rather than a database IDs + some documented endpoint path to point to other resources.

It's pretty simple – the information a client needs to transition from one state to another needs to be encoded in the documents. So if you were to design a garage door opener, a non-REST specification might say something like: To get the door status, GET https://example.com/status To open the door, POST to https://example.com/open To close the door, POST to https://example.com/close A REST approach might use a docum…

The problem I have with that explanation is that it seems to assume the existence of a universal client. How many clients are examining responses and using that to build up a UI for actions with no anticipation of what those actions might be?

Re: You know how HTTP GET requests are meant to be idempotent?

#157

Post by astura »

SoulMan wrote: post #65
beobab wrote: post #31

Earlier quoted context omitted.

That would comply with GDPR, and is a valid solution.

It is at least better than asking the email or something even to login to unsubscribe ("update communication preference")

I believe asking to login violates the CAN-SPAM Act. That being said, there might be two links, one for "update commication preference" on top and "unsubscribe" in small text at the bottom. I always ignore the first and seek the latter.

Re: You know how HTTP GET requests are meant to be idempotent?

#158

Post by ams6110 »

athenot wrote: post #151
beejiu wrote: post #15

When I recently added 'click to unsubscribe' functionality to my emails, the URL got wrote out into some logs. Those logs got written to a Slack channel and Slack loves to click any link it sees. Oh, and it doesn't respect robots.txt. But all I saw was every member of my list clicking 'unsubscribe'. It took a good hour to figure out exactly what was going on. Idempotence is not the problem here, by the way. That just…

I remember having a similar issue in 2000, before any (meaningful) client-side javascript. Solution: each link that did something also had a request_id parameter, which was a timestamp in milliseconds. Two requests with the same request_id meant the user had clicked something twice, so any action would NOT be performed multiple times if the same request_id came in more than once. This let users double click on links…

A not-small percentage of users double click links (and buttons, and anything else that needs clicking).

Re: You know how HTTP GET requests are meant to be idempotent?

#159

Post by js2 »

beejiu wrote: post #15

When I recently added 'click to unsubscribe' functionality to my emails, the URL got wrote out into some logs. Those logs got written to a Slack channel and Slack loves to click any link it sees. Oh, and it doesn't respect robots.txt. But all I saw was every member of my list clicking 'unsubscribe'. It took a good hour to figure out exactly what was going on. Idempotence is not the problem here, by the way. That just…

At 13:45 in this interview with Sergey Brin and Larry Page, you can listen to them discuss the meaning of idempotent on the air with Terry Gross. Pretty amusing thing to hear on NPR. I wonder if the term has ever been mentioned on public radio before or since.

http://www.npr.org/2003/10/14/167643282/google-founders-larr...

Re: You know how HTTP GET requests are meant to be idempotent?

#160

Post by Can_Not »

criddell wrote: post #149
jimktrains2 wrote: post #132

Earlier quoted context omitted.

You're making the mistake that this very article is highlighting: it's not just "people" who click links. An overzealous mail client or browser preloading links would force unsubscribe you without your knowledge or ability to undo. A single step, a button push, to confirm an unsubscription is fine.

> A single step, a button push, to confirm an unsubscription is fine. No, it really isn't. Lots of mailing lists operate exactly as the person you replied to mentioned where after unsubscribing you are given a chance to undo that action. That's a far more respectful way to operate.

The user isn't going to see the "Oops! I need to undo" button when their email client helps themself behind the scenes.
Post reply on HN