Earlier quoted context omitted.
/me slaps AmericanChopper around a bit with a large trout https://en.wiktionary.org/wiki/trout_slap
That’s trout abuse.
It's (presumably) more humane than whipping some llama ass.
418 I'm a teapot
61–70 of 195 posts
Re: 418 I'm a teapot
#62Many 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…
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.
Re: 418 I'm a teapot
#63Many 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…
Re: 418 I'm a teapot
#64Many 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…
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.
Re: 418 I'm a teapot
#65Earlier quoted context omitted.
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 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.
Re: 418 I'm a teapot
#66Many 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…
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.
Re: 418 I'm a teapot
#67I 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.
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
Re: 418 I'm a teapot
#68Ah yes, the "Sir, this is a Wendy's" of HTTP response codes ^_^
That’s quite a weird error to get at an Arby’s!
Re: 418 I'm a teapot
#69Many 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…
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.
That appears to be a different URL
Re: 418 I'm a teapot
#70Many 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…
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.