418 I'm a teapot
developer.mozilla.orgMany 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 numb nuts a-hole decided to add jsonip.com to an EXTREMELY widely used version of Dalvik/Android software that gets deployed to hundreds of thousands or millions of devices.
Overnight my traffic levels increased by 300%. I'm a solo dev offering a free service for 12 years. That kind of increase in traffic costs me money I've never had to plan for.
I ended up switching to Cloudeflare to handle the load with a WAF filter on the offending android tvs and other devices.
However Cloudflare doesn't properly route ipv4 address because "ipv6 is cool so we only do that" or something. Despite numerous support requests, that's still shmaybe an enterprise level feature.
I apologize to any long time users of the service. This was completely unexpected after more than a decade. I've been trying different "fixes" for 2 months and have not resolved a way to block this garbage traffic and still provide the original services.
Yea sorry I turned this funny old internet post about the mit coffee pot into a thing happening to me.
But if for some ungodly reason you're the dev or know who did it, REMOVE MY SERVICE ADDRESS FROM YOUR OUT OF DATE FROM TV/SMART DEVICE ANDROID code. You're literally fucking killing me. I've literally spend dozens of hours trying to find out if this was a contribution to a public source repo. Nothing.
Based on the Dalvik user agent, I only found a handful of references in Chinese repos. But google search is so terrible these days, even those are false flags.
So I have no idea who to contact about this. Some dipshit on your team(s) decided to abuse a free service as though there isn't a single human person behind it absorbing the costs and making sure it runs.
Could you start returning wrong answers, "country":"TW" should do it.
We had to deal with image scrapers who didn't respond to requests to stop, even if we provided an API service. I configured nginx to just serve them images of a beaver and a few 1GB junk files, they stopped pretty quickly.
Your website on https://getjsonip.com/ says:
> Supports unlimited requests and is free.
Maybe update that text? There is no guidance on acceptable thresholds, rate limits, etc.
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 piece of code somewhere that got deployed to millions of devices pretty much over night. 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.
Anyway yeah I've been evaluating changing the TOS, requiring registered signins, etc. But NONE of those fixes a 300% level of traffic that's been hitting the service for months now. I can change the verbiage all I want. But it does absolutely nothing to stop the a-hole dev from China or wherever that rolled out an update to hundreds of thousands of millions of devices with simply emailing me if that's ok.
I've literally, and successfully, run the service for free to the public because no one has done this before.
And to the nginx people. No, returning 444 doesn't seem to fix the problem. I've tried. It doesn't work.
Unethical tip: start returning the content of this article [0] to these devices. The Chinese government will "fix" the devs for you or simply block all traffic to your site.
[0] https://en.wikipedia.org/wiki/1989_Tiananmen_Square_protests...
What a big brain move, that might actually work. Unless of course the devices are being sold abroad.
Or geolocate Chinese IPs to Taiwan.
How’s that unethical?
Love it.
Unethical because it can get the devs into legal trouble and the Chinese government is known to be aggressive in their choice of "solutions".
> rolled out an update to hundreds of thousands of millions of devices with simply emailing me if that's ok.
If it's malware, they don't care if it's ok, they are malware authors. Contact your hosting provider which 100% has the ability to offload traffic from malware and ddos. They are responsible for the network and will not want malicious traffic anywhere on it, esp if it's tying up bandwidth for paying customers or premium bandwidth. If it was a large amount of bandwidth they would have contacted you long before you contacted them. I'd still reach out, they will move on it quick if it's an issue, and at the least can examine the traffic to determine if it's bad or not.
Cloudflare won't do much good here no? The requests still have to proxy back to your origin servers to spit back the ip. You can't utilize any caching on cloudflare due to the unique ip of each client. Their ddos prevention might not help because these are clients each with their own unique ip address, which is probably a cellular provider's ip space and not bad traffic. If it's the volume of clients hitting you, and not the volume of requests they make, it wouldn't trip cloudflare, or they'd be blocking major cellular address space across their entire network (which is a large portion of the internet these days)
Explicitly telling some junior software developer in China that he can call an API for free an unlimited number of times, then afterwards calling it abuse and him and a-hole dev is definitively a bit of an a-hole thing to do in my view.
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
I scanned through the comments and I don't think anyone raised the possibility that the developer might not be aware how many devices their code would be running on.
It's quite possible that a random just contracted to write software for some embedded system, with no context how many thousands or millions of devices it would run on. So they looked up OP's site, sees "supports unlimited requests and is free", shrugs and just writes implements the code.
Or, the dev might be told the system only had a couple thousand users, then somebody else copied the code and deployed it on a million devices.
You don't know the story, and I think the moral here is not to blame a faceless Android dev from China, but to implement quotas and controls and avoid falsely boast on your website that your service has unlimited scalability.
To me it just screams naivety to put up a free service, advertise it as unlimited and then calling people asshole when they make too many requests.
Personally I would never rely on a service like this since it's 100% obvious it would be sudpectible to junior developers misunderstanding what is reasonable usage.
If you're putting up an API assuming all consumers will consume it in some limited and reasonable way, then you need to rethink things a bit.
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.
> There's always an individual with autism-level consideration for what one says, isn't there?
What does this sentence even mean lmao
Autism-level consideration for what one says or not, if you say something is unlimited I'm going to take your word for it. If it's limited, tell me the limits. If it's free to a point, tell me the point. If I need to bust out the CC, tell me I need to bust out the CC.
Don't say your thing is free and unlimited if you can't handle unlimited traffic for free..
Hacker News would be on the complete opposite end of the anger scale if this was an ISP telling their users they can't actually use the "unlimited" they promised, haha
>What does this sentence even mean lmao
>if you say something is unlimited I'm going to take your word for it
The sentence refers to people like you. It doesn't make you incredibly clever to consider those sentences literally, like small children or those with under-developed empathy and theory of mind often do
It just makes you an inconsiderate numpty
>Hacker News would be on the complete opposite
Yes, there are lots of people on the tech scene that just don't get ideas like "don't abuse it", or "considering the consequences for other people"
> Yes, there are lots of people on the tech scene that just don't get ideas like "don't abuse it", or "considering the consequences for other people"
It's not abuse if you say it's free and unlimited and someone uses it freely and unlimitedly! This is why sites have acceptable use policies and terms of service. This is why most sites don't say their tool is free and unlimited.
It is what those words mean. It is literal. If I read an acceptable use policy and then went on to use it in a way that is not allowed that would be silly.
> The sentence refers to people like you
> It just makes you an inconsiderate numpty
Speaking of "like small children or those with under-developed empathy and theory of mind", I'm not sure these were needed. Can we just discuss things? I promise my mind is open whether you insult it or not, I'm just not convinced by the argument at this point :)
I hope you got a nice slither of dopamine out of namecalling though in any case, haha
>It is what those words mean. It is literal.
>I'm not sure these were needed
The original wording I was gonna use before deciding to be more considerate was "small children and autists"
If you can think of another short descriptor for "people who obtusely take things literally and are unable or refuse to account for other people's state of mind", I'm happy to use those instead
>I hope you got a nice slither of dopamine out of namecalling though in any case
In fact, it was far more than a sliver!
Upon further reflection, I think I got a lot of repressed anger for never having smacked people who can't behave unless they are explicitly told to do so, who actually need the "within reason" clause everywhere, and who are happy to play with technicalities when it comes to justifying their behaviour
You do make an aggressively fair point. I've also enjoyed the banter if nothing else :)
I dunno if my mind is changed just yet but if I'm honest with myself adding it to a widely deployed app would be in my 'dick move' category.
Just set your own up, or use a DNS method which comes with the bonus of built in caching.
For what it's worth I've never actually taken anyone up on their unlimited offers, I try to keep my services neat and tidy :)
> Yes, there are lots of people on the tech scene that just don't get ideas like "don't abuse it", or "considering the consequences for other people"
Got to love the cleverness with the people who design services with the assumption that there are no such people and then goes on to hackernews and cries when a kid in China breaks their site. Lol.
Insanely incompetent.
In the context of an ISP, what is abuse in terms of network usage? For instance, I'm sure with console + PC gaming etc. a lot of gamers use around 400GB a month on average. Systems evolve, and it's the ISPs' job to keep up with demand.
Think of your average engineer doing mobile development. "Here, hit this url to get the device ip". They write the code, it makes 1 request. The average backend engineer isn't performance focused, why would the average mobile engineer be thinking about a distributed denial of service against some third party api? Most mobile engineers have to be guided to not slam their own backend servers, and do not approach problems in their sphere with the mindset to prevent this type of issue. Not knocking mobile devs, it's just literally not something they have to care about most of the time, and imo only the ones who go out of their way to have a solid understanding of the backend systems would even understand what's in play here
Besides that, odds are that this is malware of some sort hitting this service to get the infected device's public ip to phone it home for use in a command and control situation, and if so, they don't care that they are slamming this service.
Mobile devs who care about this type of thing will not need to make any sort of outbound connection anywhere to get the device ip address, it's right on the device already. These what's my ip sites are used by script kiddies and malicious software running on anything
"There's always an individual with autism-level consideration for what one says, isn't there?" isn't needed and I'd advise you to be more professional, or at least more human.
Relevant SMBC (especially to the sibling comments, holy shit): https://www.smbc-comics.com/?id=2095
It says that you can call it unlimited number of times, not millions of devices that you’re selling.
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.
This would be very valid comment if toasters had manuals telling that they are perfectly safe to use while sleeping.
If you lie in your marketing material then you may put yourself in a mess. Big surprise.
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.
Sure, you specifically can use it million times, or even more (given your span of life).
If your audience is millions of users it’s millions * millions, not cool.
So if someone doesn't undeestand this assumption, then they are an asshole?
That's pretty crazy viewpoint.
> So if someone doesn't undeestand this assumption, then they are an asshole?
Yes.
> That's pretty crazy viewpoint.
Companies that make millions of devices while abusing free APIs without giving anything back are assholes. Hmm, let me think?
No, it’s not.
You must be living in a bubble if you think that's how companies operate.
Saying that someone is an asshole for using an API in a way which clearly should be possible according to the documentation is a very clear sign of that person being a junior developer who don't have actual real world experience of anything except toy projects. Any developer with some years of experience would understand that this would happen and he should not be surprised over it.
It's very possible that no one involved in this is even aware of this issue, so automatically calling them assholes is somewhat incompetent at best.
> Companies that make millions of devices while abusing free APIs without giving anything back are assholes.
If a service is free & "unlimited" and they start using it, and you get mad, then that is not their fault, it's yours.
It says:
> Supports unlimited requests and is free.
Typically "unlimited" is more than a million.
Water in a lake is also technically free (depending on local laws), do I have to make it clear that inviting millions to take a cup out of it is not a good idea?
This is the internet? If there are a million people around the lake fond of tea then of course you need to tell them that they can't consume all the water. Offering a free service and being upset when people use it is just naive.
> 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, or us something like cloudflare/waf. It's not fair that you have to eat the cost, but it's not fair that someone else does either.
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.
Do you have a way to donate?
That appears to be a different URL
One is a marketing and docs site, the other is the "api".
Wikipedia had a similar situation with a single flower image being requested so many times. I can't find the story and don't remember it well, but I think it was a big indian company using this image to check if internet was available.
IMHO, one of the problems is that many dev. don't realize both the size of their company and the impact of so many requests.
I hop you'll find a solution, and thank you for your service!
PS: maybe you should create a dedicated post about this subject to attract visibility
Oh yes! I remember that!
[1]: Wikimedia Phabricator link: https://phabricator.wikimedia.org/T273741
[2]: HackerNews thread: https://news.ycombinator.com/item?id=26072025
That’s typically why it’s a good idea to include a crappy “generate API” key button so you can block traffic like this, you don’t even need a registration process - someone can just email with reference to their API key to discuss their issues.
> you don’t even need a registration process
You should put it behind a CAPTCHA of some sort however, otherwise, some smartass will just write a "library" auto-fetching an api key as soon as the one it has currently cached stops working.
And yes, that is an annoyance to users, but so what? Please direct all complaints to the comparatively small number of people responsible for the fact that the rest of us cannot have nice things.
This is not really a problem, you can easily disable generating new keys and sidestep the problem. Everyone who's legit can keep using their old keys.
CAPTCHA is for humans while this json service is for machines
icanhazip.com had similar issues. Cloudflare took over the project https://major.io/2021/06/06/a-new-future-for-icanhazip/
Fyi, dns can be used to obtain public ip from large companies, without the overhead of tcp and http
dig +short txt ch whoami.cloudflare @1.0.0.1
dig +short txt o-o.myaddr.l.google.com @ns1.google.com
dig +short myip.opendns.com @resolver1.opendns.com
What does the "ch" mean?
You're a better person than me. I'd start returning nonsense like `999.9` to see if I could trigger a ton of bug reports for someone.
other evil ideas:
- return a 200 with broken JSON, possibly triggering parse errors or exceptions in the caller
- return a payload that generates catastrophic resource consumption on the other end, e.g Content-Encoding: gzip and feed it a deflate bomb
- hack TCP and/or TLS to leave the other end waiting/stalling in an attempt to rate limit (timeout) or starve resources (ulimit) on the other end (e.g abuse 3 way handshake)
The site advertises itself as free for all and unlimited usage. To suddenly return malicious responses to intentionally break these apps might very well be illegal in many countries, or maybe would make them liable for damages claims. These clients are not violating any TOS or doing anything not allowed, after all.
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, because that would be damaging to me in the first place.
Given the scale of the purported app causing this it's very much abuse in its own right, whether intentional, misengineering, or an oversight. The author of jsonip.com seems to have taken every precautionary measure to limit damage and identify perpetrators to reach out, and these failed. Ethically I feel it would be only fair to displace damage from their infra to the app in order to protect themselves. The only alternative is to shutter the service as it's essentially experiencing a financial DDoS.
> 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 that they don't know that they don't know yet. These issues of slamming a backend server are pretty common and mobile devs don't know to avoid it until they cause it imo. This could also be malware too which wouldn't care about decency.
Point is, scale your service, adjust your terms, start rate limiting, or shut it down. Calling your users names is the wrong solution no matter the user's intent, and solves exactly zero of the issues at hand.
The service owner should feel proud to have such a popular service, many folks will never have to deal with scaling issues. As the saying goes "scaling issues are good issues to have".
> 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.
> scale your service
Scaling is done entirely at the expense of the service provider, so, not a sustainable option (and AIUI already done so as to continue serving for other users, but at terrible cost). Scaling issues are good to have when you have customers, not when you personally foot the bill.
> adjust your terms
At the very least changing terms won't change the already deployed app instances. In each of the three delineated scenarios it won't even register a blip on the abuser radar. So, not an option.
> start rate limiting
Pretty sure that was attempted. This is DDoS, rate limiting means doing it across the board, impacting every user, including those in good standing.
> or shut it down.
The only effective option. a.k.a the nuclear option a.k.a We Can't Have Nice Things.
> get someone's attention
That's the end game of these gray tactics. Not wreaking havoc but triggering awareness in a last resort way so that dialog can be opened/corrective measures can be taken. Note that "shut it down" would presumably have a similar effect, so there's no real harm done in practice.
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.
Unfortunately, this seems to be the pattern that people offering the same service as you experience.
Take a look at https://major.io/2021/06/06/a-new-future-for-icanhazip/, if you haven't seen it already.
Thanks for the link. That's like reading something from a really scary personal future.
Sorry but I laughed aloud at all the swearing! But yes, I empathise complelely with your situation. People abusing someone else's free service really gets my goat. I hope this situation is resolved soon.
I do agree with one of the other comments - returning something about Taiwan or Tiannenmen square may do the trick
I’d love to know more about
“However Cloudflare doesn't properly route ipv4 address because "ipv6 is cool so we only do that" or something. Despite numerous support requests, that's still shmaybe an enterprise level feature.”
jgc@cloudflare.com if you can share your interactions with us.
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 useless additional traffic. We are still hyper curious what on earth is loading us and for what reason though. AFAIK we couldn't see translation requests from them, just loading our website.
Welcome to the internet. Install pfsense/opnsense and run your own firewall at home and you'll be shocked at the flood of non-stop portscans hitting your ip getting blocked. This is par for the course and there is nothing you can do to prevent it, you have to build systems able to mitigate, offload, block bad actors. This will always be the case.
Any free service that has utility will be quickly scripted against and used to make someone else money. Build accordingly
You mentioned low income countries. This could be infected devices running ancient unpatched OSes, but what if the traffic is legit, coming from impoverished countries who found your service and use it to teach their children and learn things they'd otherwise not have access to?
Personally I would deep dive the traffic and try to determine the intent behind it, you could be destroying a future generation's potential, and not blocking malware I'm assuming you can correlate the requests from those ips with that they are translating. Odds are someone is hitting your service to translate for their paid service, but if it's an important part of a poor country, I'd find a way to allow it to keep happening
> AFAIK we couldn't see translation requests from them, just loading our website.
Browser homepage? Or maybe the unlucky victim of a "connectivity check/am I online" recurring task
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.
Couple things to consider
1. Check your competitors who return json and see if they have a Location header 301'ing or 302'ing all their traffic to your service (if the client follows redirects).
2. Reverse dns lookup your origin ips and see if anyone has a domain's dns pointed at your service. Check the Host header on your end and make sure it's your domain as well as ensure your web server and/or proxy are not blindly accepting traffic for `*`/any host, and make sure it's serving only your host
3. Ip address headers can be spoofed. It might not be coming from where you think it's coming from
> However Cloudflare doesn't properly ... Despite numerous support requests, that's still shmaybe an enterprise level feature.
This matches my experience. I'd use the CF free plan assuming no guarantees for a low risk site like my personal site, and I'd use the expensive enterprise plan where I'm paying individually for features and quota, but I'd never use the middle-ground "sure it's unlimited!" plan – it's far too vague about what it _actually_ provides.
Ironically, "sure it's unlimited" is now a thing the parent comment has probably learned not to say too.
> That kind of increase in traffic costs me money I've never had to plan for.
https://web.archive.org/web/20200811215649/https://getjsonip...Going further with jsonip Plus With the upcoming Plus service, you get special features and even more information about your users. - All of the free service features - IP geo location - Country and city to within best available accuracy - ISP Info - Time zone data - Full referer data - Browser and OS infoA paid service has been "upcoming" since at least August 2020, which would subsidize the free tier usage you allow on your site. Aside from the ISP and geo data, everything else is given to you in the request headers or can be determined with the ip address (geo can get tz).
If it's costing you money, shipping the Plus features might offset your out of pocket expenses.
This is a failure of growth/capacity planning and lack of a proper TOS that clarifies "unlimited within reason and at our sole discretion with no SLA or warranty of any kind for non-paying users", as well as failure to ship any monetizing features 3 years after announcing it.
Contacting them to have them stop wouldn't solve your problems. What happens when the next million devices get random updates from literally anybody that starts doing it again? Try to implement rate limiting, optimize your hot code paths, watch out for slow clients (buffered reverse proxies), needless header parsing, slow template rendering, etc. Any language capable of concurrency should be able to handle 100s of thousands of requests on a cheap vm. The client ip is coming to you in the request headers and all you do is print it back to them... A go handler would be a few lines of code to do this and that's including dealing with reverse proxy real-ip type stuff. You don't need to allocate an actual struct and serialize into a json object, just printf a hardcoded string with a replacement for the ip from the header, or better yet benchmark the fastest solution.
I'll do it for you, I'm looking for a job ;)
You assumed the issue relates only to compute costs. Even with a small payload, bandwidth fees can add up quickly when millions of clients are polling.
Building the paid features announced 3 years ago would pay for compute as well as bandwidth. If the service runs at a loss after that, shut it down or start reaching out to these companies that have integrated it into their products and ask them to sponsor the service, which will certainly be cheaper for the company compared to the cost of dev time to change to some other service that can shutdown just as quick, QA the updates, iterate, approve, ship, wait for adoption, triage bugs, manage all the people doing those things, etc.
Or better yet update the TOS to be free and unlimited for non-commercial use, and to contact sales for commercial use with an estimate of request volume, then sign a phat enterprise contract and rest easy
This. It's mainly bandwidth costs that are the issue. Dealing with cpu is easy and cheap. Bandwidth is the mind killer.
>as though there isn't a single human person behind it absorbing the costs and making sure it runs.
Obligatory https://xkcd.com/2347/
You are a legend. Many hugs.
I hate to add to your headache, but multiple pihole ad blacklists contain your domain. It looks like https://winhelp2002.mvps.org/ may be the original source of the blacklisting.
hosts file (modified) sourced from; Steven-Black - hosts @GitHub : https://github.com/StevenBlack/hosts
cat /etc/hosts |grep -i 'jsonip.com'
0.0.0.0 jsonip.com 0.0.0.0 www.jsonip.compihole and other dns blocklists would reduce traffic to their service, not increase it
Yeah but it means their service is less valuable. If adblockers block traffic to that domain then there's less incentive to pay for the service because an undetermined but ever growing percentage of traffic will block it.
Now it's a headache for a different reason.
Sounds like you’ve built a valuable service that large companies are using in production! Why not start charging for it?
Have been thinking about it for a couple years. People generally don't realize the complexity that gets added when you start charging money for something.
> You're literally fucking killing me.
Literally being killed? Call the police!!!11
> literally fucking killing me
Wow, that's crazy.
No, sorry this is 100% on you. You should have implemented throttling, and daily query limits. Once you put something on the internet for free, you can't complain then if people are using it.
> you can't complain then if people are using it.
Yes he can complain, and bombarding a free service for unlimited requests isn't okay.
For starters because the people doing that, will usually be among the first to cry when the free service stops being free, blocks their requests or suddenly requires an API key.
> bombarding a free service for unlimited requests isn't okay
Hummmm.... OP's website on https://getjsonip.com/ says:
> Supports unlimited requests and is free.
Seems like we have a bit of a contradiction here.
Back in highschool, my friends and I got kicked out of a buffet restaurant. Every movie I've ever seen a poster for suggests that it's "Only in Theatres", yet I've held many a DVD release in my hands.
There's something about reasonability and fair-use and use over time going on here, but I just can't put my finger on it.
You didn't get kicked out, you got played. They bank on the fact that most people will eat less than the price of admission, kinda almost like the ones who under eat the admission cost subsidize the ones who overeat the admission cost. Kinda like the paying customers for a service usually subsidize the running costs of the free tier. The buffet advertised all you can eat, you paid them, that's a contract. Unless there's fine print that you agreed to, you had no obligation to leave before you had your fill if they were open still. America 101, contracts and liability for breaches of contracts.
For example here's the Backblaze team verifying that their unlimited personal backup is indeed unlimited, with one single user storing 430TB for $6/month. The users spending $6/month who use a couple GB more than offset the cost of the 430TB guy. If your business model doesn't support the ability to get in the black, you have a failing business. This isn't the user's responsibility to fix, it's the failing service with a bad business model.
> As you can see, we lose money on a few customers at the high end (we cannot store 430TB of data for only $6/month), but since more customers just want to be reasonable and backup their laptops we are profitable and fully sustainable on the "average"
> Somebody who is costing Backblaze $2,150/month and is only paying $6/month :-)
https://www.reddit.com/r/IAmA/comments/b6lbew/comment/ejlbsq...
I see no contradiction.
There is a difference between gracefully and responsibly using something that is offered for free, and just bombarding it with requests like no tomorrow.
People can of course do the latter. But then they don't get to complain when at some point, the available offerings present walls of legalese instead of a few simple and clear statements, and the user experience goes from seamless and easy to "Click here to register an API Key"
It all depends on the nature of the work you are doing.
One thing is to own a service that's used by 10 MAU and you extend the service with a job that calls the OP's service 100 times a second. That's bad, you are using way more than you need.
Another thing is to own a mobile app used by 10M MAU and you embed the OP's service into the app. That's not bad intention, you just added a new service to your app. The problem is that the OP's definition of "unlimited" is not really unlimited.
You can say that the local community water well has "unlimited uses", then complain when Nestle comes over and takes all the water.
No difference here.
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.
I would have agreed if it was a piece of source code. For example if you put a bit of code on the internet using a permissive license and it is good, don't complain that some tech giant took all your work for themselves without giving you anything in return. By choosing that licence you explicitly told the world that doing this is fine. Also, using someone else source code doesn't incur recurring costs on the author's part.
But here, you are actually taking resources from the author. That's something that is not only rude, but also puts the user at risk. The author is really nice for maintaining service, he could have just stopped it, or even served malicious payloads. After all, there is no contract saying that he should be nice. Here, despite the strong language, he is trying to stay nice instead of just cutting a service that many people rely on, which he has all right to do.
Throttling and daily query limits would make the service unreliable and not so different from cutting it off completely. Keep in mind that it is not a single user abusing the service, it is many users who got redirected there by an abusive app. He could have used the "API key" that is suggested here, but it is a hurdle that will affect usability.
Yeah maybe, but in this day and age it's completely unreasonable to expect anything from users. You need to expect the worst and if your system is not prepared for it, then sorry, it's badly designed. There are many anti-abuse measures and if you're deliberately not using any of them, then that's on you.
You absolutely can. Nobody has an obligation to serve you if you are an asshole.
Why complain instead of mitigating? Or why not complain AND mitigate at the very least?
Do not serve it to assholes?
> Or why not complain AND mitigate at the very least?
You mean, like they say they have been trying to do, in the complaint?
I am replying to you saying that "you absolutely can [complain]". The comment to which I replied simply states that you can complain. Sure, you can. shrugs
I’ll never understand “no complain” argument.
Person has a valid complaint, goddamnit, they have all the rights to complain.
Sure, feel free to complain away if that makes you feel better.
I mean, we've all got a right to grievances.
I honestly use this a lot when I'm testing, because it's basically the only response that can show up where I know god damned well that it's only happening because I programmed it to happen under certain conditions.
edit: a common one for me is that if any test passes a post request without a csrf token... sorry, I'm a teapot, because I forgot to add a csrf token to that form.
I like to respond with 418 as the catch all response code for mock web services for requests that dont match any installed expected requests. The reasoning is sometimes 404 is a valid mock response for some test cases, so I needed the "404 for mocks" that would never appear on any legit service. Very clearly highlights when something is going wrong on a test.
It’s still in my production code, usually in places where i don’t expect code to ever lead to.
It’s just my general “something particularly odd has happened” response.
I've never worked on a webserver but doesn't 500 seem better suited for that condition?
Yes. And write something to the logs, so you can find out there's a bug before users call your helpdesk. Arguably that's the most important part of any 5xx error.
It's a bit of a purist argument, but 4xx series means the client can fix something and get a better response.
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 bug that should be fixed.
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...
500 is correct.
But nobody enjoys a 500 so I occasionally use 418 for extra unexpected situations.
I do this too for the same reason, but also for the next person that looks at my code to give the joy of laughter.
Why not respond with an error message saying that there’s a missing CSRF token?
A teapot isn’t precluded from delivering an error message per spec
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.
I felt compelled to verify httpcats has it covered and it does:
That url is way too long. I prefer https://http.cat/.
also dogs
> 218 This is fine
Is this the one that gets sent if the server temperature rises above 80 deg?
This is always my go to if I have to do fun custom error pages
Every time this pops up, I'm reminded of the day that the NPM registry started returning 418 responses for users accessing it via corporate HTTP proxies.
I remember being at a training course that day and my manager asking me what we could do to fix it because our CI was failing to pull dependencies from NPM.
Trying to explain that NPM was returning a status code intended as an April Fools joke and which was never meant to see the light of production was quite difficult
Perhaps I can fix a lot of things but debugging a response code that isn't meant to exist is not one of them.
I remember that day. As a more junior developer I was very confused as to what I had surely done wrong.
Over 20,000 teapots out there:
https://search.censys.io/search?resource=hosts&q=services.ht...
I think there should be a "555 Bad Timer" error for when servers can't keep up or are running slow. Like a "429 Too Many Requests" error but it's the server's fault.
;> 555 timer IC - Wikipedia : https://en.wikipedia.org/wiki/555_timer_IC
I'm looking forward to the extended protocol Sugar bowl.. A parody of 'I'm a Little Teapot' : https://en.wikipedia.org/wiki/I'm_a_Little_Teapot
'I'm a little teapot short and stout... here is my handle... here is my handle... Oh fv<k!, I'm a sugar bowl'
I'm more amused by "A combined coffee/tea pot that is temporarily out of coffee should instead return 503 [Service Unavailable]".
Kinda thought this should respond 404
A 404 would mean that the client should not expect to find coffee there at all, which in this case would actually be better replaced by 418. However, if coffee can be found, just not right now, then it's the server's fault, so a 5xx code is in order, and 503 fits the bill best.
Someone that actually knows proper HTTP semantics on HN? I'm positively surprised.
On a related note, my favorite easter egg header:
There was a movement to protect this HTTP code from boring committees: https://en.wikipedia.org/wiki/Hyper_Text_Coffee_Pot_Control_...
Protect the code!
I like it when people come together for something so silly.
Ah yes, the "Sir, this is a Wendy's" of HTTP response codes ^_^
That’s quite a weird error to get at an Arby’s!
Found this while scouring this list of HTTP status codes, because I wanted to make sure I was giving appropriate responses in this web API I'm developing.
Its rather funny, isnt it. But I wonder what the context is. Why they added it.
It was added as a joke, and kept because (according to https://save418.com)
> “It's a reminder that the underlying processes of computers are still made by humans”
Stupid reason imo. Adding childish humor to a protocol seems like harmless fun until you remember how much of a mess network protocols, and their specs, and their implementation is. Maybe you think a 418 error page is funny, but I think you’ll appreciate it a lot less when your application gets a rather confounding error because some service provider wanted to remind you that the underlying processes of computers are still made by humans, rather than implement the actually correct response.
/me slaps AmericanChopper around a bit with a large trout
That’s trout abuse.
It's (presumably) more humane than whipping some llama ass.
I thought it was handling fish under discuss m suspicious circumstances.
...
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.
Sure, but I’ve actually had to debug a few 418 errors on production workloads, and none of them involved teapot services. Knowing that the implementers of the error thought it was a hilarious joke certainly didn’t make the experience more fun.
Nope, it’s still unfunny, it should have been deleted then and there. In fact, it has.
No, it's a great canary in the coal mine. Anyone who doesn't implement proper handling of 418 gets their general error handling facilities tested (4xx).
What is the correct way to handle a 418? As if it were a 500? A 400? A 403? A 404? A 429?…
418 is a class 4xx error, which means the client erred and shouldn't repeat the request as-is. That is, any unrecognized error beginning with a 4 must be handled as if it were the base error class, 400, "Bad Request".
> the server cannot or will not process the request due to something that is perceived to be a client error (for example, malformed request syntax, invalid request message framing, or deceptive request routing).
Must be fun at parties
https://en.wikipedia.org/wiki/Hyper_Text_Coffee_Pot_Control_...
Started off as an April's fools joke, people liked it enough to keep it in.
It was an April Fools Joke
I came across this a while back that I enjoyed but is kinda just an “lol” but not super useful status code thing:
https://github.com/3digitdev/Haiku-TTP-Codes
Doesn’t have any for 418 yet though… a PR may be in order!
I'm a pot for tea // short and stout, that describes me // tip me over now.
Teapot's witty brew, HTTP 418, "I'm just a teapot."
Binance will send you 429s if you hit their rate limits. If you continue to do so they'll hit you with a 418 and then blackhole your traffic.
Twitter used to respond with status code 420 and the message “enhance your calm”
That's a fun one. Not sure why you're downvoted for the anecdote.
I bet that makes Elon feel warm and tingly inside.
Make sure you pre-allocate a buffer that is short and stout
Ensure it’s long enough for a json map of handle and spout objects
The weirdest HTTP code I've heard of is LinkedIn giving 999 for when it doesn't like your IP address.
russian MoD sites started returning this for foreign IPs shortly after the invasion began last february
I use this in my API, for when it is called without any query parameter.
I also return a teapot emoji as the response body.
I've seen a 418 response on a production system once... on a simple request that took 5 seconds to be fullfiled.
Building integrations for duct-taped legacy systems in finance is fun.
it was steeping!
Glad to see that this is supported across all browsers.
Had to think of https://yourmom.zip
Is anyone ever going to use that tld for anything non malicious, non prank, and instead something actually actually serious?
I was thinking of using it for phishing tests maybe, other than that nah
no
I lol'd.
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.
The whole point of protocols is to get the same results on the same situation regardless of server implementation. What could possibly be gained by returning intentionally different error codes?
I wasn't thinking of "error-codes' but rather "status codes". An ID of a resource, running on the web could unify it uniquely, not really the physical machine but the server-application we are talking to. But maybe it's enough that we have URIs?
there already is a system kinda like that. try this command to see the unique status code representing the fact that HN's server is up and running:
curl https://news.ycombinator.com/ | base64So... if the API I use switches from Apache to nginx, I have to rewrite all my success/error handling?
Of course not, the error-codes should remain the same standard ones as always. I'm saying there are more numbers than those, which could be used for some as yet unidentified purpose.
Perhaps a unique status-code of a server could identify things like the version of content served by it.
That's what ETag headers are for. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ET...
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.
As an SRE, please don’t use this for internal tools to be cute. It’s not helpful, and in 5 years time when you’re long gone and something breaks at 2am, it’s incredibly frustrating.