See "Important Programming Concepts (Even on Embedded Systems) Part I: Idempotence"
You know how HTTP GET requests are meant to be idempotent?
201–210 of 313 posts
Re: You know how HTTP GET requests are meant to be idempotent?
#202Or dont your doors to the internet.
Re: You know how HTTP GET requests are meant to be idempotent?
#203Earlier quoted context omitted.
It's updating the thumbnail screenshots. This only happens if you have the Safari "blank page" be your favorites instead of either your "home page" or a truly blank page.
> if you have the Safari "blank page" be your favorites instead of either your "home page" or a truly blank page. Yay for modern user friendly applications making simple words like blank completely meaningless and ambiguous.
That's on the poster -- Safari calls it "Top Sites", with explicit options for "Empty Page", "Home Page", etc.
Re: You know how HTTP GET requests are meant to be idempotent?
#204Hello! 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.
> I should have used "side-effect-free" instead of "idempotent" in my tweets The HTTP term is "safe method". Although you weren't even wrong because section 4.2.2 of RFC7231 (i.e. HTTP) defines all safe methods, including GET, as idempotent. I think they use this language because nothing is truly side-effect free. In fact GETs can have side-effects, the most obvious of which is writing the fact of it to a logfile, an…
IMO "side-effect free" is always a statement constrained by the operating level of abstraction. Logging is not an effect at the level of the application, but rather some subset of it's context (system, db).
I love that term and am going to use it as much as possible
Re: You know how HTTP GET requests are meant to be idempotent?
#205The 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'm not seeing how this is an issue with the browser as much as the server handling the request. Safari provides a feature that shows thumbnails of frequently visited sites; these thumbnails are loaded with a header specifying its for a preview. It's on the server to understand that a GET request _by definition_ should not have side effects (like toggling the open/closed state of a door), and optionally to perform special handling when seeing the preview header.
Re: You know how HTTP GET requests are meant to be idempotent?
#206Earlier quoted context omitted.
Of course a doubling function is not idempotent! I think the confusion arises because side-effectful functions can be considered as having type f :: (RealWorld, OtherArgs) -> (RealWorld, OtherOutputs) and so for a garage door toggle you have something like t :: RealWorld -> RealWorld where the new state is the old one with the door opened/closed as appropriate. Now the idempotence condition becomes: t(t(world)) == t(…
But `GET(GET(x))` doesn't make sense, in general (and if it did, then you would not expect it to be idempotent), so clearly idempotency in this context is meant to mean side-effect free. They should probably just say side-effect free, though, to avoid the confusion.
It's possible to be idempotent without being side-effect free. If you PUT some record, for example, then that operation _will_ have side effects (modifying the record). If you then PUT that same data again, the result will be the same (it's idempotent).
Re: You know how HTTP GET requests are meant to be idempotent?
#207Earlier 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 :/
I got just the thing for you:
https://gist.github.com/hraban/10c7f72ba6ec55247f2d
Every time you write some code you need to remember removing before commit, surround it with a comment containing "NOCOMMIT". With this script as a pre-commit hook, git will echo an error message and fail.
E.g.:
print("debug: ", myval)
print("debug: ", myval) # NOCOMMIT
Re: You know how HTTP GET requests are meant to be idempotent?
#208Earlier quoted context omitted.
The user isn't going to see the "Oops! I need to undo" button when their email client helps themself behind the scenes.
Yet somehow lots of places use the click-one-link-to-unsubscribe method and it seems to work. What are they doing differently? The follow up confirmation screen feels slimy to me like some kind of cable company retention tactic. That's why I called it a dark pattern.
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.
Re: You know how HTTP GET requests are meant to be idempotent?
#209Earlier quoted context omitted.
A not-small percentage of users double click links (and buttons, and anything else that needs clicking).
The wording is a little ambiguous, but I think the scheme was that the first request is honored and any subsequent requests are ignored, not that additional requests cancel or undo the action altogether.
Thanks! Yes I didn't word that properly. :(
Re: You know how HTTP GET requests are meant to be idempotent?
#210Earlier 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.
None of your responses acknowledge or challenge the very real problem that automated systems and expected behavior of GET reqeusts impact your desired behavior of click-to-unsubscribe.
In the spectrum of "buttholedesign", using proper web standards to make sure an action is being taken deliberately is far lower than "intentionally low-contrast skip buttons" and "call to cancel subscription".