Sheel Bedi
Sheel Bedi

Sheel Bedi

I'm a little teapot...

Photo by Roman Synkevych 🇺🇦 on Unsplash

I'm a little teapot...

Or, my favorite Github issue

Sheel Bedi's photo
Sheel Bedi
·Jun 30, 2022·

3 min read

A few years npm users around the world encountered a very peculiar error; when using newer versions of Node behind a proxy, they would receive the error code 418 - more famously known as "I'm a teapot" - when attempting to install or upgrade dependencies.

This appears to be the Github issue for that incident. Apart impact, prevalence, and severity of this issue, a couple of things about it stand out to me.

This is the only time I've seen a 418 error in the wild. The 418 error code was originally created as an elaborate April Fools' Day joke. However, the joke has appeared to take on a life of its own. I was surprised to learn that there are some real world uses of this error; apparently the core Nodejs framework does so, and has rejected the suggestion to drop this feature. Interestingly, on both the thread for Nodejs, and a similar request to drop 418 from the Go programming language, specific posts the thumbs down reactions outnumber thumbs up by about ten to one; in other words, if you believe this unscientific polling method, the pro-418 camp outnumbers the opposition by that margin. I think that's a cute piece of internet lore.

There's also a more substantive issue. It's not until you read several posts down into the thread that someone reads and posts the full response body of the error:

{"error":"got unknown host ("}

Following up on this message, this user was able to determine that affected npm clients were appending the port to the Host header when connecting through a proxy, causing requests to fail. The Nodejs team determined that this was the root cause of the issue, and specifically thanked the diligent poster for the information.

Prior to this comment, however, quite a few npm users weighed in saying that they also encountered this error. However, other than the error code itself, they didn't provide anything more than environment and version information, as well as the fact that they were behind a proxy. While this information was helpful in isolating the error specifically to newer versions of node that were behind a proxy, it looks like a lot of people didn't do much investigation of their own. I wonder if this behavior - seemingly turning the matter over to someone else by default, rather than looking deeper - says something about human nature.

We rightfully expect that when there's a bug, the relevant technical team - in this case, the core team of the Nodejs community - will take the lead in fixing. After all, with their power to make changes, and their presumably greater product knowledge, such a team should be best positioned to solve the problem.

However, Nodejs is an open source project - users aren't really paying for a product, or any level of service. Moreover, even if this were Enterprise software, with customers paying for the product and for support, one would still expect some investigation or additional information from them, and the first response from any support team in such a situation would be to ask for more information.

There are two implicit ideas in this expectation. the first is that people who consume software in this manner, ie as part of their own source code, are still developers, and it's reasonable to expect some more sophistication from them than one might in a typical consumer tech support situation. Additionally, support/dealing with a technical problem is a team endeavor, requiring knowledge, cooperation, and attention to the matter from the user as well as the team behind the software; the user is ultimately the only one who observe and investigate the issue as it is experienced on their end.

In an age where the customer is always right, I think that's something that's too easy to forget.

Share this