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

271–280 of 313 posts

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

#271

Post by boomlinde »

downer68 wrote: post #249

This, kids, is why GET requests should be idempotent. Or, like, you know, how about a browser only sends a request when I'm actually fucking asking for something, and doesn't try to fetch everything I've ever thought about, with my every slightest accidental finger twitch against its touch screen? What happened to deterministic user interaction?

Well, ideally you'd have both. When I "GET" I assume that it's GET as opposed to any of the other standard HTTP methods, not "GET" as in Indiana Jones getting the golden idol from the pedestal.

This is not only a problem with browsers preemptively requesting URLs, but also when it comes to caching. What happens when the URL I'm GETing is cached? Absolutely nothing, as far as the original server is concerned.

The current situation with browsers doing smart things to make slow websites appear fast is a bit like compiler writers doing smart things with UB in C, though. Speed a lot of things up by utilizing every undefined nook and cranny of the spec, breaking tons of legacy software that make pretty sound assumptions about how things actually work. I use a bunch of poorly designed legacy systems where GET often has intentional side effects. They break because the browser starts issuing HTTP requests long before I have finished typing an address. Let slow sites be slow and leave the speed problem to the people that should be dealing with it instead.

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

#273

Post by CoolAndComposed »

dragonwriter wrote: post #262
NewEntryHN wrote: post #222

GET requests aren't supposed to be idempotent. They're not supposed to change state in a first place.

> GET requests aren't supposed to be idempotent. RFC 7231 disagrees. > They're not supposed to change state in a first place. Well, yeah, GET is supposed to be safe, but all safe methods are also idempotent.

Just because a server announces HTTP/1.1 doesn't mean it conforms to that specific RFC.

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

#274

Post by dragonwriter »

CoolAndComposed wrote: post #273
dragonwriter wrote: post #262

Earlier quoted context omitted.

> GET requests aren't supposed to be idempotent. RFC 7231 disagrees. > They're not supposed to change state in a first place. Well, yeah, GET is supposed to be safe, but all safe methods are also idempotent.

Just because a server announces HTTP/1.1 doesn't mean it conforms to that specific RFC.

That non-RFC-compliant implementations of HTTP exist irrelevant to what properties HTTP methods are supposed to have, which is the issue under discussion.

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

#275

Post by greglindahl »

saalweachter wrote: post #269
greglindahl wrote: post #244

Earlier quoted context omitted.

Was it blekko? We had a website owner email us about that issue when blekko's ScoutJet crawler was new... although I don't recall the bit about ignored redirect headers.

I'm pretty sure everyone with a crawler has hit this sort of problem before. The first startup I was at did with someone's wiki that had "delete" links everywhere with no auth.

Now that I've hit it once, I watch out for websites with this problem. I was surprised to notice that a Fortune50 tech company's internal employee-personal-webpages-maker-thingie had that issue. And then a week later they asked me if I could crawl their internal web. Uh, no, who knows what other internal systems had that problem?

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

#277

Post by wpearse »

nothrabannosir wrote: post #207
wpearse wrote: post #55

Earlier quoted context omitted.

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) becomes: print("debug: ", myval) # NOCOMMIT I end up relying on this every day I program. Can't go bac…

Thanks! I'm not sure how easy it would be to put the git hook on all my machines though? I have a collection of laptops (and one desktop) that I work on and I often don't use the same machine for a few weeks :-/

I ended up using a "env.h" file... is there a C-equivalent of the PHP (?) .env file?

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

#278

Post by wpearse »

nwsm wrote: post #181
bawana wrote: post #167

forgive my density, but why would you make a web page trigger a toggle when it is loaded? shouldnt there be a button or some other user interaction to initiate the state change? Is it like loading a web page for the weather- so that when the page is loaded it goes and 'GETS' the latest weather info? Is it for convenience? So that all you have to do is go to a webpage and have it do stuff?

I think there was a homepage with a "toggle" button, the toggle button redirected to /toggle. site.com/toggle then got added to his favorites by safari. So it wasn't loading the site with the button, but the site that the button redirects to.

Correct. Site now has a form and a button. /toggle now responds only to POSTs, and redirects back to /.

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

#279

Post by tedunangst »

jimktrains2 wrote: post #135
icebraining wrote: post #115

Earlier quoted context omitted.

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

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!

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

#280

Post by wpearse »

Kihashi wrote: post #195
wpearse wrote: post #55

Earlier quoted context omitted.

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

It's possible to remove that from the history of your repo, although it breaks any forks. https://rtyley.github.io/bfg-repo-cleaner/

Heh. I think I did worse ... made a local copy of the repo, nuked it on GitHub, then re-created the three commits by hand ... less credentials.

That looks like a much more useful tool, though.

Post reply on HN