Live data from Hacker News

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

twitter.com

291–300 of 313 posts

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

#291

Earlier quoted context omitted.

GET is meant to get, not set. Since 1.0. https://www.w3.org/Protocols/HTTP/1.0/spec.html#GET > The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI

So what? If I never intended for the GET to be GOT, then the browser is just as much at fault for such unintended consequences.

That’s the whole point of HTTP request methods: it isn’t. GET should never cause such side effects. The entire web is built with these principles in mind precisely so that problems like this don’t happen.

If you want a slower browsing experience feel free to disable prefetching in your browser, but this isn’t a hill worth dying on.

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

#293
post #282
post #29

Hello! Long-time lurker, and guilty dev behind the garage door. You can see the (broken) code I wrote here: https://github.com/wpearse/wemos-d1-garage-door-wifi I'll get around to fixing it later this week. Also, an apology: I should have used "side-effect-free" instead of "idempotent" in my tweets.

Please, for the love of all that is holy, don't post long-form content on Twitter.

I'm sorry. This is the first time I've used a thread. I won't do it again!

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

#294
post #282

Earlier quoted context omitted.

Please, for the love of all that is holy, don't post long-form content on Twitter.

I'm sorry. This is the first time I've used a thread. I won't do it again!

Actually, I think I actually wrote this story just so I could try out the "new" (months-old?) threading feature. I don't much twitter.

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

#295

Earlier quoted context omitted.

I don't think it's slimy. They could provide a simple, complete unsubscribe button in addition to a list of subtopics to check/uncheck. Maybe I only want to unsubscribe from their blog, or I still want to receive feature update news but not their sales catalog.

If I click a link to claims to unsubscribe me, then that's exactly what it should do. I have no problem with a page to manage account preferences, but don't label the UI element that leads there as unsubscribe .

Do you also not like links called "Contact"?

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

#296

Earlier quoted context omitted.

And when a user receives an email saying they've been unsubscribed because an automated system prefetched the link, they won't be concerned or worried or confused at all. (Especially when this happens _every time_.

And then the automated system clicks the undo link... Problem solved!

Which fires off a new email thanking them for re-subscribing.

Soon your inbox is full.

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

#297
post #58

Well, a while ago I saw this code (on my own project!): window.open("?controller=users&action=changePassword&name=" + user_name + "&password=" + password) I was horrified, glad it isn't live yet, and I fixed it immediately. But I'm still wondering whether I was so sleep-deprived or drunk when I wrote this. It's over SSL, so it should not be that big deal, but still, GET shouldn't be used for such things.

It's a big deal since it will be visible in access logs in plaintext, so if the logs are compromised your users would be too.

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

#298
post #127

This is pretty much the classic newbie web developer mistake, heard many stories about people making it when they first start. I've also seen people fuck up in the opposite way, using POST when they should use GET and having unexpected behavior. Though not usually as "funny" as the classic "using GET instead of POST" errors are. This concept of HTTP request methods really should be explained to new developers in a mo…

What are some of these unexpected behaviors associated with using POST when you're meant to use GET?

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

#299
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…

It should be a DELETE imho or a PATCH.

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

#300
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…

The problem is not that your endpoint had side effect. Rather, it didn't have any side effect(it is supposed to unsub, and it does exactly that).

The problem is with lack of authentication. Slack's ability to unsubscribe people on their behalf, without their explicit permission seems to be the real issue here.

Even a "I'm not a bot" check would provide some protection.

Post reply on HN