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.
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.
> Supports unlimited requests and is free.
Maybe update that text? There is no guidance on acceptable thresholds, rate limits, etc.
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.
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
[1]: Wikimedia Phabricator link: https://phabricator.wikimedia.org/T273741
[2]: HackerNews thread: https://news.ycombinator.com/item?id=26072025
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.
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
- 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)
Take a look at https://major.io/2021/06/06/a-new-future-for-icanhazip/, if you haven't seen it already.
I do agree with one of the other comments - returning something about Taiwan or Tiannenmen square may do the trick
“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.
Any free service that has utility will be quickly scripted against and used to make someone else money. Build accordingly
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
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
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.
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 info
A 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 ;)
Obligatory https://xkcd.com/2347/
cat /etc/hosts |grep -i 'jsonip.com'
0.0.0.0 jsonip.com
0.0.0.0 www.jsonip.comLiterally being killed? Call the police!!!11
Wow, that's crazy.
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.
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.
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.
It’s just my general “something particularly odd has happened” response.
It also works perfectly in case it accidentally gets pushed to production.
curl https://news.ycombinator.com/ | base64Perhaps a unique status-code of a server could identify things like the version of content served by it.
Not saying such a feature is needed just wondering could it be useful for some purpose.
> “It's a reminder that the underlying processes of computers are still made by humans”
Started off as an April's fools joke, people liked it enough to keep it in.
Is this the one that gets sent if the server temperature rises above 80 deg?
https://github.com/3digitdev/Haiku-TTP-Codes
Doesn’t have any for 418 yet though… a PR may be in order!
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'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'
Protect the code!
Building integrations for duct-taped legacy systems in finance is fun.
https://search.censys.io/search?resource=hosts&q=services.ht...
I also return a teapot emoji as the response body.