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

141–150 of 313 posts

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

#141

Post by dalore »

thomasz wrote: post #72
rusk wrote: post #44

Earlier quoted context omitted.

I'd just like to clarify that what you have described here is "safe" rather than "idempotent" [0]. Easy mistake to make, made the same mistake myself, idempotently (that is to say you only make it once ;) Get, and NOOP, are both "safe" and naturally "idempotent" since the former encompasses the latter. [0] https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

GET must be safe and idempodent. In the context of http, idempodency basically means that you get the same result for each request with the same url and the same set of parameters. Toggle should be implemented as post, since it’s neither safe, nor idempodent.

No not the same result. How would the front page of any news site work then?

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

#142

Post by jimktrains2 »

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 :/

git add -p

It will let you approve each hunk in a file to commit or not.

git commit -e -v

Will force you to edit the commit message and in the editor show you the diff of the commit against HEAD.

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

#143

Post by astura »

phab wrote: post #130
astura wrote: 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…

GET requests are specified[0] to be idempotent: > Methods can also have the property of "idempotence" in that (aside from > error or expiration issues) the side-effects of N > 0 identical > requests is the same as for a single request. The methods GET, HEAD, > PUT and DELETE share this property. [0] https://tools.ietf.org/html/rfc2616#section-9.1.2 edit: formatting

Looks like the RFC talks about idempotence from a "side effect" perspective where I was talking about it from an "output" perspective (the generated HTML).

I agree with the RFC and I mistook what the person meant

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

#144

Post by jimktrains2 »

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.

Another big deal is that it'll get stored in server logs too.

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

#145

Post by bartread »

icebraining wrote: post #115
mysterydip wrote: post #113

Earlier quoted context omitted.

Having a single confirmation step to prevent "oops" clicks doesn't seem like a dark pattern to me.

Confirmation steps should only be used if the action can't be easily undone.

It can't be easily undone if it was "clicked" by an automated process rather than a human being.

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

#146

Post by ams6110 »

aptwebapps wrote: post #21
groestl wrote: post #19

Earlier quoted context omitted.

Just be the guy who says "oh a POST is fine" first

Yeah, full REST is nice, but you can do worse than just using GET and POST as long as GET doesn't change state.

I've had to develop APIs for clients that could only do GET or POST requests. Sometimes you have to sacrifice correctness for what's actually possible.

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

#147

Post by jimktrains2 »

chrisseaton wrote: post #102
reza_n wrote: post #90

To me this sounds like a CSRF problem. There's no token or session associated with these calls, so a browser was able to inadvertently CSRF the calls. Changing this call to POST or PUT would still leave this API vulnerable.

It's not about access control, it's about the fact that browsers are free to make speculative GET requests whenever they like, and they actively do to pre-fetch pages. His GET end-point was pre-fetched by his browser, activating the door. This would still happen even if there was a token or session associated.

Not just browsers, but any service.

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

#148

Post by notheguyouthink »

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 my opinion. The author makes it sound like that would be fine.

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

#149

Post by criddell »

jimktrains2 wrote: post #132
cjrp wrote: post #116

Earlier quoted context omitted.

The majority of people who clicked on the link did it on purpose, so a better pattern would be to make it unsubscribe immediately with a "didn't meant to unsubscribe? click here to undo" link afterwards.

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.

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

#150

Post by zzbzq »

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 invent hackneyed fixes like CORS.
Post reply on HN