Live data from Hacker News

418 I'm a teapot

developer.mozilla.org

171–180 of 195 posts

Re: 418 I'm a teapot

#171

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?

Re: 418 I'm a teapot

#172

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.

So... 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.

Re: 418 I'm a teapot

#173

Earlier quoted context omitted.

> 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.

> 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.

Re: 418 I'm a teapot

#174

Earlier quoted context omitted.

So... 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...

Re: 418 I'm a teapot

#175

Earlier quoted context omitted.

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.

Re: 418 I'm a teapot

#176
post #164

Earlier quoted context omitted.

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.

Re: 418 I'm a teapot

#177

Earlier quoted context omitted.

Why complain instead of mitigating? Or why not complain AND mitigate at the very least? Do not serve it to assholes?

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.

Re: 418 I'm a teapot

#178
post #87

Earlier quoted context omitted.

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

Re: 418 I'm a teapot

#179
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…

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.com

Re: 418 I'm a teapot

#180

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'

Post reply on HN