Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

418 I'm a teapot

developer.mozilla.org

Post reply on HN
Print view View original

161–170 of 195 posts

Re: 418 I'm a teapot

#161

Post by pksebben »

ransackdev wrote: post #150
lloeki wrote: post #146

Earlier quoted context omitted.

I said "evil" for a reason. That said, it seems like a _single_ actor is causing 300% cost increase compared to _every other actor combined_. Even if advertised as free, there's decency to be had. If I lend someone my home without TOS and say "make yourself at home" there's a reasonable common sense expectation from both parties that visitors should not turn on every water tap and electric device full blast 24/7, bec…

> there's a reasonable common sense expectation Your logic error is in assuming all people have common sense and setting expectations based on that assumption. This actually has nothing to do with common sense, a jr and sometimes even senior mobile devs would not have the mindset of avoiding a ddos to a third party api when writing a feature that needs to get the device ip. It wouldn't be on purpose, it would just be…

> Calling your users names is the wrong solution no matter the user's intent, and solves exactly zero of the issues at hand.

True, but returning fire with malformed responses or other such tactics could absolutely solve:

> assuming all people have common sense

.. sometimes effective communication starts by doing what you have to IOT get someone’s attention.

Re: 418 I'm a teapot

#162

Post by leobg »

ransackdev wrote: post #157
leobg wrote: post #147

Earlier quoted context omitted.

Why? There is no guarantee give to victimize that service for free forever.

There's a huge difference between blocking traffic to keep your servers online (you are the good guy) and returning payloads that are intended to break consuming services (you are the bad guy, performing a premeditated malicious act on unsuspecting devices, across state lines)

Maybe. Sorry for the auto correct.

Re: 418 I'm a teapot

#163

Post by crote »

ricardobayes wrote: post #155
Dudeman112 wrote: post #116

Earlier quoted context omitted.

There's always an individual with autism-level consideration for what one says, isn't there? No, effectively DDOS-ing a service just because it says it's free and unlimited is a dick move People like those are a big reason for why we can't have nice things

Can you imagine a fast food restaurant franchise CEO to complain how annoying it is that people ask for copious amounts of free ketchup? If you don't have a policy or anti-abuse measures, don't complain that "people are using too much" of the free stuff. That's ridiculous and detached from real life.

That one random guy asking for ten or twenty packets of ketchup every once in a while isn't the problem. Sure, it's weird, but he does put it all on his fries and he does eat it all, so that's just part of offering free ketchup.

However, would you still call it "detached from real life" if suddenly the manager from McDonalds starts showing up daily, filling a 100-gallon drum with ketchup because it is "free"? In law there is such a concept as a "reasonable person", which exists precisely to avoid people abusing loopholes like this.

Re: 418 I'm a teapot

#164

Post by crote »

AmericanChopper wrote: post #78
kQq9oHeAz6wLLS wrote: post #46

Earlier quoted context omitted.

... Nope, it's still funny, we're keeping it.

I promise that knowing it’s supposed to be a joke is _not_ going to make you less frustrated if you ever end up having to debug a non-descriptive 418 error. To make it worse the description and the error code aren’t even consistent. 4xx is a client error, but your web server being a teapot is definitely a server side problem.

No, it should be a client error. The error is intended to be returned when a client has asked a teapot to perform a coffeepot-only operation - which is obviously a mistake on the client side.

This makes it similar to 405 Method Not Allowed, 406 Not Acceptable, or 426 Upgrade Required.

Re: 418 I'm a teapot

#165

Post by KomoD »

junon wrote: post #117
KomoD wrote: post #112

Earlier quoted context omitted.

Last I checked unlimited is more than millions

This mindset is why we need "do not use while sleeping" warning labels on toasters and hair dryers.

No, advertising unlimited and then complaining when someone truly does use unlimited is not a problem with my mindset, it's a problem with the person who runs the service, if you don't want people to truly use unlimited, don't advertise unlimited.

Re: 418 I'm a teapot

#166

Post by geuis »

maccard wrote: post #132
geuis wrote: post #70

Earlier quoted context omitted.

Yeah I know. That is a legit critique. What's been happening is your essential black swan event. I've been running the service for 12 years and have never had this problem. There are hundreds of websites and independent users that have never abused the api like this until March. I have always been able to absorb the traffic impact. This is different. Someone wasn't thinking and randomly added the domain to a lazy pie…

> The only way I've been able to keep jsonip active is by incorporating Cloudflare. But they don't actually solve the problem. As a corporation, they treat ipv4 addresses like 3rd class citizens. Don't get me wrong, you're doing the world a service with your service, but why should cloudflare have to handle your problem for free? If you want to resolve your problem, it sounds like it's in your hands - block traffic,…

Oh, I never expected Cloudflare to handle the problem for free. I would happily have at least a pro level account with them if they treated ipv4 traffic properly. But they don't expose a request's actual v4 address to the backend. The WAF works amazingly well, but it otherwise breaks a critical part of the service.

Re: 418 I'm a teapot

#167

Post by geuis »

timbuchwaldt wrote: post #127
geuis wrote: post #59

Many years ago, some person misconfigured their squid proxy and was hitting https://jsonip.com to the point my server at the time was turning green in the gills. I started responding with 418 "You are a tea kettle" or something like that to those specific requests. The originating dev actually paid attention to their error messages and quickly resolved their config issue. Fast forward to March this year. Some fucking…

We see your exact Dalvik problem on deepl.com as well. We get a constant flood of those requests, sometimes subsiding. They are globally distributed, preliminary in lower-income countries. We have tried lots of things, like letting them just time out, returning different errors, redirecting of many sorts including Android intents, no solution. They now made it to our permanent blocklist and we just deal with the usel…

That's interesting. The traffic sources hitting me seem to be the opposite. Mainly US, Western Europe, and other better well to do places around the world. I suspect a lot of the traffic is from apps on smart devices. I've seen user agents that reference Bravia tvs for example.

Re: 418 I'm a teapot

#168

Post by scoofy »

JimDabell wrote: post #96
scoofy wrote: post #74

Earlier quoted context omitted.

abort(418) is just quick and easy and gets the job done… even if I wasn’t the one reviewing the code it would throw up enough confusion to get attention. It also works perfectly in case it accidentally gets pushed to production.

It doesn’t get the job done though… for anything non-trivial multiple errors can occur and if you just abort(418) then you don’t know which one it is. If you generate a real error message you can include some actually useful information. “This is some kind of error I triggered” is not anywhere near as useful as “The error is…” .

I mean, yea, I can pass a message with the 418 if I just have:

return "this error, blah", 418

I understand your point, and it's a good one. I really don't need to use 418, I just find it useful. I think the key is that when I see that 418 error, I know it's something I put in there at once.

I also think a naked 418 is a bit cleaner if it did end up on my production server, just because I'm not tipping my hat too much by returning anything about what's happening behind the scenes.

It could be a lot cleaner if I did everything by the book, but where I use this is just my hobby project, and I'm just going for doing as much as I can quickly, and the mental energy that goes into error handling could easily add very significant time. Again, you're not wrong, and it would be better if i clearly articulated these errors in the long run.

Re: 418 I'm a teapot

#169

Post by prerok »

sholladay wrote: post #65
prerok wrote: post #53

Earlier quoted context omitted.

Hmm, I don't think it's that purist. All my HTTP clients have the logic that 4xx is a non-retryable error, i.e. if I repeat the request I will always get the same response unless something is changed, whereas 5xx means that something is wrong on the backend and I should retry it later. It is true I have often encountered inconsistencies in implementations but I do think that when that happens it really is a backend b…

There are some 4xx codes that should be retried. 408, 413, and 429 at the very least. There are also cases where it makes sense to retry 404, such as when polling for a resource that is being created and will soon be available.

You are right about the 429, of course, and my more "advanced" clients take it into account and only reissue requests after the requested backoff time. The smaller "stupid" clients error out, as they should, because a dumb retry would just cause "angrier" responses from the server.

I am not sure about the other two though.

413 definitely does not seem retryable, if the client continues sending too large content. Special handling would be needed to break down the data into smaller chunks and when I encounter this error I just break it down to smaller chunks beforehand so built-in handling is not needed.

Never encountered 408. It might be because I never keep connections too long...

Re: 418 I'm a teapot

#170

Post by galaxyLogic »

skeeter2020 wrote: post #19
galaxyLogic wrote: post #15

There is no shortage of numbers. I wonder if it would make sense for every web-server ot have its own status-code if up and running? Of course they would have to be registered somewhere.

This has nothing to do with servers though. It's in context to the requested resource. If you want to check if a server is alive it's happening several layers below an HTTP request.

Right, but, the word "server" is often used to refer not to the physical machine, or even a virtual machine, but to the "web-server" meaning a running instance of Apache nginx or IIS. etc.

Not saying such a feature is needed just wondering could it be useful for some purpose.

Post reply on HN