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

61–70 of 313 posts

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

#61

Post by latchkey »

XorNot wrote: post #59
latchkey wrote: post #51

I have a small (golang) agent that runs on over a thousand raspberry pi class machines (not on the open internet). The agent has a GET /reboot api because it is really convenient to be able to just hit that url in a browser window when we need to. Adding all the no-cache headers to the response seems to have worked well enough to prevent browsers from randomly hitting the url. I just added a check for the x-purpose h…

This still seems like really bad idea when the POST request is right there. Serve a page with a button saying "are you sure"?

A reboot of the machine isn't the end of the world and far less risky than a garage door randomly opening. It probably needed it anyway as they tend to degrade over time. This is a very specific usecase. If it becomes an issue, I can always push out an update of the software that switches things to POST (thanks to using the golang library, overseer).

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

#62

Post by dogma1138 »

wpearse wrote: post #55
speps wrote: post #43

Earlier quoted context omitted.

EDIT: it's actually his address, I thought it was just a coincidence but you can the house on Street View... I removed the actual name as doxxing isn't great, sorry.

Thanks. Not the address with the WiFi garage thankfully. I was actually thinking "better not commit that" ... before, y'know, I committed it :/

Well looks like a nice neighborhood at least.

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

#63

Post by falcor84 »

amelius wrote: post #52
someonewithpc wrote: post #45

Earlier quoted context omitted.

No. A function which multiplies a number by two is side effect free, but is no idempotent.

Except if the domain is zero.

Or even a slightly more exotic case, such as Z mod 2 (a single binary digit)

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

#64

Post by onion2k »

z3t4 wrote: post #56
groestl wrote: post #11

Idempotency might be necessary for GET calls, but it's not sufficient. Imagine he had two separate GET calls (opened/closed): the author would still have the same problem. Browsers assume GET to be safe (non-mutating), and safety implies idempotency.

HTTP GET is nice because you can "debug" via browser. But I don't think it's a good protocol choice for opening/closing doors nor any other service not related to document requests.

It's trivial to debug a POST in a browser if you can open the console. https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequ...

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

#65

Post by SoulMan »

beobab wrote: post #31
poizan42 wrote: post #22

Earlier quoted context omitted.

What would the problem be in just showing a button that says "Confirm unsubscribe" that sends a POST request? A lot of sites does something like that for their newsletter unsubscription.

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")

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

#66

Post by pletnes »

wpearse wrote: 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.

No side effects means no garage door opening or closing. I guess you wanted it to open or close in some cases at least?

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

#68

Post by mseebach »

someonewithpc wrote: post #45
bjackman wrote: post #39

Earlier quoted context omitted.

Anything side-effect-free is idempotent too, I suppose

No. A function which multiplies a number by two is side effect free, but is no idempotent.

I think that is considered idempotent in the REST-sense of the word: you can multiply a number by two as many times as you like, the result will be the same (and no state is mutated).

I looked it up, apparently there's a formal definition "denoting an element of a set which is unchanged in value when multiplied or otherwise operated on by itself", which does not seem to describe the REST usage very well, though.

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

#69

Post by StavrosK »

bjackman wrote: post #42
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…

Aren't you allowed to have your "click to unsubscribe" button lead to a page with a button that does a POST that actually unsubscribes? I feel like I've seen that approach in use.

What they do is load a page with a form redirect to do the POST, I believe, so link loaders won't follow it and you'll be safe.

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

#70

Post by dogma1138 »

MrMid wrote: 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.

Well you don’t seem to validate the existing password prior to authorizing the change.

Good CSRF protection on GET requests is also near impossible to implement as GET is intended to be a “safe” request as in a request that does not modify a state but this isn’t something that is actually practiced.

Post reply on HN