32 ms·

NPM proxy users receiving ERR 418 I'm a teapot

294 points by spondyl 8y ago

tiles 8y ago
Relevant comment by wgrant: The body of the 418 is {"error":"got unknown host (registry.npmjs.org:443)"}. Looks like some npm clients are appending the port to the Host header, but only when going through a proxy, and that's confusing the registry. It seems to be based on combination of npm:node version.
- hn_throwaway_99 8y ago
  Sure, but why is anything in the chain returning the 418 "I'm a teapot" error message? My guess is someone wanted to use some code for "I don't really know what this error is", saw the 418 and thought "that's cute!" Be careful, "cuteness" and "cleverness" has a way of biting you in the behind.
  - hluska 8y ago
    Ha! I used to use 418 as my "everything is completely fucked and there's no way everything will ever get that fucked, so this is the best code possible" status code. It took about a year for me to internalize that things will often be that fucked. :)
    - simplecomplex 8y ago
      500 “Internal Server Error” is the code you should be using for generic server errors.
      - 49bc 8y ago
        Yes a 500. Not sure how anything else would ever pass the smell test of even a lazy pull request.
      - curun1r 8y ago
        It's important to say why that's the correct error code. In this case, it's because 5xx errors can be retried in the future whereas 4xx errors tell the client that any retries will receive the same response.
        eropple 8y ago
        This is honored more in the breach than the observance at times, though, particularly with 404.
        boomlinde 8y ago
        In general, this is wrong. 4xx status may be retried, achieving different results each time. This makes sense with for example status 409 and 429, where this is definitely expected, or 404 since resources may be added or removed at any time independent of any single client, or 402 and 403 which may change out of band. Conversely, there are 5xx statuses that you shouldn't expect to change with each request, for example 505 (HTTP version not supported) or, really, 500 in some cases. There's AFAIK no standardized strategy to deal with the different status code. Instead it's important to get the status code right to as accurately as possible describe the error to the client. The server never tells the client what to do; it tells it what went wrong so that the client can deal with the error at its own discretion. In this case the server told he client that it was a teapot when what actually happened was an internal server error. That's wrong because it's wrong, not because every client will or even should deal with either of these errors in a predictable way.
        curun1r 8y ago
        > There's AFAIK no standardized strategy to deal with the different status code While I was a bit too over-broad in my generalizations of 4xx vs 5xx status codes when it comes to retries, the gist is still the same. The specification does specifically call out when it's okay to retry and when it isn't. And it also specifically calls out when it's okay for intermediate servers and browsers to cache responses and when it isn't. In the case being discussed, 500 is specifically the correct error code because it cannot be cached and can be retried. That's not the case for 409 or 429, which either cannot be retried automatically (409) or can be cached (429). 402 is, IIRC, underspecified and shouldn't be used. 403 specifically states that the request should not be retried. It's important to make a distinction between the user/application and the user agent when we talk about retries. The user agent is the program or library that implements the HTTP spec. You seem to be talking about the former, who is always capable of retrying a request when they feel circumstances have changed enough for the request to succeed. But user agents are intentionally dumber. They can't resolve conflicts, fix permissions or do anything outside of the logic dictated by the spec. And they have much more limited license to retry 4xx responses or cache 5xx responses.
      - yeukhon 8y ago
        Actually, 503 is better in this case. Internally it shlkld report 500.
      - hluska 8y ago
        I'm sorry that I wasn't more clear. The person I was replying to aptly wrote "'cuteness' and 'cleverness' has a way of biting you in the behind", and I was agreeing with/adding to that comment. I've been guilty of cleverness and sure enough, it has usually found a way to get me in the end. Today, in similar situations, I'd return a 500 with a message in the body.
      - sofaofthedamned 8y ago
        I've seen the teapot error used when the internal route of a request was circuitous (many servers involved) and a 500 could have come form anywhere. It was used as a canary, and only on this codebase which was bought-in and absolutely awful.
      - K0nserv 8y ago
        No it's not since this is a error on the client's side it should be a 4xx code, probably not 418 though.
    - astura 8y ago
      500 is the correct error code to use in that case.
    - jmvoodoo 8y ago
      It's 4xx so it should be used only to represent an issue with the request/client, not the server :)
  - nmjohn 8y ago
    > Be careful, "cuteness" and "cleverness" has a way of biting you in the behind. Generally speaking I tend to agree, but in this specific case how is sending a 418 "biting you in the behind" worse than sending a more proper 500 error? (Or perhaps a 400? Hard to say exactly, feels like the server is having unexpected errors since it cannot properly parse the hostname.)
    - reificator 8y ago
      If I'm doing quick generic error handling, I'm going to assume anything in the 500 range is a server issue and display an error of the sort. If it's in the 400 range I'm going to handle the common ones and then assume it's the client's or user's fault. (And of course a user fault is really a client validation fault.) So yes, returning a 4XX for a 5XX is problematic.
      - nmjohn 8y ago
        But is that relevant to _this specific_ case? The problem is not 3rd party clients, it's the npm client itself - so I don't know how error handling is relevant? (In the general case, yes of course it is, but in this and the parent comment I'm specifically talking about issues in only the narrow use case here.)
        reificator 8y ago
        Being first party doesn't mean it's the same person/team writing both sides. And error handling is always relevant.
        tedivm 8y ago
        The error was on the server side, not the client side. The server was not following the HTTP spec. The fact that it was server side was why they were able to fix this so quickly. Since it was a server side error, and the issue was not a client side one, the 500 error code is most appropriate. The fact that the npm client itself is the first one to trigger this error is not the issue here, as it could have just as easily been yarn or another client. Following standards are important, and we weren't trying to make tea.
  - nneonneo 8y ago
    The origin server (registry.npmjs.org) is the one throwing the 418, so they're primarily to blame. Some intermediate proxy server has decided to send a somewhat unusual Host header (registry.npmjs.org:443 instead of the usual registry.npmjs.org), and the registry server barfs up a 418 in response.
  - jwalton 8y ago
    As per https://tools.ietf.org/html/rfc2324 https://tools.ietf.org/html/rfc2324, the server is throwing 418 because it is a teapot, and can't brew coffee. Perhaps this is a coffeescript related problem.
    - fyfy18 8y ago
      I’m not sure if this is really compliant to that spec either. It states that error code should be returned when attempting to brew coffee - which means the BREW or POST method is used - but this is using the GET method.
      - stephengillie 8y ago
        Has a BREW call been used? The spec might not support out of order operations. That should be tried before any further GET attempts against the coffee interface.
  - rejschaap 8y ago
    > Sure, but why is anything in the chain returning the 418 "I'm a teapot" error message? My best guess? The request ended up at a teapot and the poor thing was asked to do something that no teapot has ever done before.
  - nonconvergent 8y ago
    There's nothing clever about returning the wrong error. That's anti-clever.
- nneonneo 8y ago
  Can confirm: $ curl -vvv -H 'Host: registry.npmjs.org:443' https://registry.npmjs.org:443 > GET / HTTP/1.1 > Host: registry.npmjs.org:443 > User-Agent: curl/7.54.0 > Accept: */* > < HTTP/1.1 418 I'm a teapot < Date: Tue, 29 May 2018 03:52:16 GMT < Content-Type: text/plain;charset=UTF-8 < Content-Length: 53 < Connection: keep-alive < Set-Cookie: __cfduid=d3f8dd8d2121ede348194ee142443bccc1527565936; expires=Wed, 29-May-19 03:52:16 GMT; path=/; domain=.registry.npmjs.org; HttpOnly; Secure < Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct" < Server: cloudflare < CF-RAY: 422601de4bf49fc6-IAD < {"error":"got unknown host (registry.npmjs.org:443)"} Per RFC 7230, §5.4 (https://tools.ietf.org/html/rfc7230#section-5.4 https://tools.ietf.org/html/rfc7230#section-5.4), the port is optional if it's the default for the URI (:80 for http, :443 for https), but nowhere in the spec does it say it's an error to include a redundant port specifier. The registry server is likely noncompliant here, and it definitely should not be throwing 418 here. (400 would be appropriate if the Host header was malformed - but that's not even the case here).
kasey_junk 8y ago
Comments about the error not being helpful! Presumably the npm community is full of web devs. Given that how can they not know the http codes, especially one as famous as 418?
- sk5t 8y ago
  I'd argue that 418 veers more towards "trivial" than it does "famous." Expecting knowledge of more than 400, 401, 403, 404, and maybe 412 is pushing it.
- whatsstolat 8y ago
  I didn't know 418 and I'm a web dev. Http status codes are a tiny part of my job
  - 49bc 8y ago
    Not only that, but if you’re returning this status code you’re almost certainly doing something wrong or user hostile.
    - matte_black 8y ago
      What if it really is a teapot? Not that farfetched with today's internet connected devices.
      - hedora 8y ago
        There’s the EKG+, an internet connected smart kettle: http://fellowproducts.com/shop/staggekg/ http://fellowproducts.com/shop/staggekg/ I have the plain EKG, and quite like it. However, both are designed for pour-over coffee, so can’t correctly return 418.
      - deleted 8y ago
        [deleted]
      - 49bc 8y ago
        I still don't think returning a 418 (in the realm of client errors) is the correct code, even if it is a connected teapot which you're trying to identify! I think the appropriate action would be a client sends an HTTP HEAD to the service, which responds 200 "TEAPOT".
vorpalhex 8y ago
Really disappointed in NPM lately. These past few months have been downright silly. How many major problems like this affect other package managers?
- swyx 8y ago
  what else in these "past few months" are you referring to? as a moderate npm user i am blissfully oblivious.
  - losingthefight 8y ago
    Not OP but maybe he is referring to the big in which the npm upgrade bumped to a non-ready version and caused havoc on production systems by overwriting permissions and files: https://github.com/npm/npm/issues/19883 https://github.com/npm/npm/issues/19883 That was the end of February, so not sure but that may be it.
    - jjeaff 8y ago
      There was also the issue where npm filter bots accidentally expelled some large, legitimate users and then made the namespace available, thus allowing random people to take the packages over, and inject code into any applications that used those projects.
      - erichurkman 8y ago
        This is one of the scariest aspects to modern development. Thousands of applications are one bad actor away from ruin. We're incredibly vulnerable. Chrome extension gone rogue? Package repository allowed duplicate packages? A contributor's GitHub key was hijacked? Imagine uBlock Origin's Chrome extension author creds were hacked. "He" publishes a new version of the Chrome extension that monitors coinbase.com and fakes the transfer/confirmation screen, or submits transfers in the background. The extension has "write" access on all sites, so the rogue extension can also monitor your Gmail and silently inject a filter that routes trade confirmations to trash. Or the "requests" library in Python gets an update to replicate 2FA codes via Twilio to a 3rd party. Sure, you can do pinning and cryptographic signatures to verify that v 1.0.0 of X is really what you expected. But who audited 1.0.0 of X in the first place...?
danschumann 8y ago
The last comment is locking the issue because too many people are responding saying the same thing. This comment makes me want to reply and say the same thing too, but I can't now.
- freditup 8y ago
  Locking a discussion with zero-unreasonable responses as "too heated" is bad optics, but I think locking the discussion is a pragmatic decision, as the NPM team has been alerted about the issue and any meaningful comments would get lost in the noise otherwise.
  - stonogo 8y ago
    Instead, they're just regular lost. Not much of an improvement.
  - phyzome 8y ago
    It's likely that the "too heated" is GitHub putting words in the mouth of the repo admins. I don't think you get to choose the text of that message. ETA: The options are "off-topic", "too heated", "resolved" and "spam". It looks like you can also elect to not give a reason, though...
  - gpvos 8y ago
    One of the last few messages before that, by wgrant, was helpful in solving the problem. They might have missed that if they had closed the thread a little bit earlier.
- thsowers 8y ago
  I think this is one reason GitHub rolled out the "thumbs-up" reactions, too many comments just state "+1", which pollutes actual technical discussion, but at the same time it is crucial to know if many people have the same issue
- yeukhon 8y ago
  If they are annoyed by the spam, they can “mute”.
minikomi 8y ago
Perhaps it really is a teapot.
- itgoon 8y ago
  It isn't being asked to brew coffee, though, so it's a mis-use of the spec.
  - d4n1elchen 8y ago
    Or maybe you're asking a teapot to install npm packages.
- duxup 8y ago
  Maybe we all are...
  - Mithorium 8y ago
    we are ALL teapots on this blessed day :)
Abishek_Muthian 8y ago
A moment of sympathy for the engineers who have to explain their non technical project manager on why their application is getting this error.
- rdtsc 8y ago
  I learned my lesson not put cutesey messages in the logs the hard way. I was young and dumb and in my case it was for a restore from backup system. A customer had failed hardware and was trying to restore from backup. It was failing and the funny message all of the sudden didn't sound too funny when customer was reading it back to me in their own voice over the phone.
  - DrJokepu 8y ago
    Oh I’ve done that too as a rookie. Software displayed an error message when the application was in a state that was impossible for it to be in, at least in theory. The error message was a line from 2001 Space Odyssey: “I’m sorry Dave, I’m afraid I can’t let you do that”. Of course when it ended up getting displayed it was displayed to a customer called Dave who has never seen (or read) 2001 Space Odyssey. The first lesson was to avoid funny error messages in the future. The other was that “impossible” things tend to happen surprisingly frequently in software.
    - DoreenMichele 8y ago
      With 7 billion people on the planet, one in a million events are guaranteed to happen to about 7k people. Law of stats of large numbers etc
      - zitterbewegung 8y ago
        More like birthday theorem applies here .
      - mlyle 8y ago
        There's a lot of different possible 1 in a million events, though...
deleted 8y ago
[deleted]
purephase 8y ago
My favourite HTTP response...
- donpdonp 8y ago
  https://http.cat/418 https://http.cat/418
forapurpose 8y ago
It actually reads like an IoT protocol, way ahead of its time in 1998. Life not only imitates art, but eventually catches up with parody: https://tools.ietf.org/html/rfc2324 https://tools.ietf.org/html/rfc2324
- FroshKiller 8y ago
  I suspect the joke was inspired in part by a certain well known coffee pot monitoring system that preceded it: https://en.wikipedia.org/wiki/Trojan_Room_coffee_pot https://en.wikipedia.org/wiki/Trojan_Room_coffee_pot
incadenza 8y ago
I’m sure the anti-NPM brigade is on its way, but I recall there being a huge backlash against removing this error code from Node a few years ago.
- pluma 8y ago
  The problem isn't that Node supports this error code. The problem is that it's used by the registry. Heck, technically the problem isn't even that it's used by the registry, the problem is the npm client is a broken untestable mess and users seem to routinely unearth extremely surprising bugs. This all has very little to do with teapots. The fact they used 418 and didn't provide a useful error message only makes it more interesting to talk about.
  - incadenza 8y ago
    Yeah, fair point.
btown 8y ago
Is it too soon to call this Teapotgate?
- jugg1es 8y ago
  It's 'too soon' until the water is boiling. Then it's 'tea time'.
- hartator 8y ago
  It’s tea soon.
- deleted 8y ago
  [deleted]
- gtremper 8y ago
  Teapot Dome
umurkontaci 8y ago
> I'm gonna lock this for now, because I'm sure it's gonna get plenty of traffic. You really don't need to respond to repeat what every other poster is saying. The registry team has been informed. It's alright if they want to lock the thread to prevent a massive +1 spam, but at the very least they should have given a link to track the status of this. When your production systems are down, "thanks for the report" is not a good enough response.
- olingern 8y ago
  Something more along the lines of: > Thanks so much for the report. Currently, we are doing the best to resolve the issue. Please continue to check back on our status page to see our updates. https://status.npmjs.org/ https://status.npmjs.org/ Sounds more appropriate
- ludston 8y ago
  Isn't it? I would rather get an update after the problem has been fixed than to know that development efforts have been slowed down in order to keep me in the loop. I am not sure if you are putting your money where your mouth is. This product can be used for free, and there is a simple work around. (i.e. Test before you upgrade.)
  - yegle 8y ago
    https://cloudplatform.googleblog.com/2017/02/Incident-management-at-Google-adventures-in-SRE-land.html https://cloudplatform.googleblog.com/2017/02/Incident-manage... is a good article re how Google handles incident. In an incident, constant and clear communication is a key.
    - ludston 8y ago
      Different scope. This is definitely how to handle incidents like, "our live production service is currently having issues" because there are critical consequences. e.g. When a system that I have worked on goes down, trucks would literally be parked at the border of different states and countries waiting for clearance. This is a different magnitude to, "I upgraded my free dependency management tool, and now I have to downgrade it. Please tell me when I can upgrade again."
iends 8y ago
2 hours after the incident was responded to by an npm employee and the status is still green: https://status.npmjs.org/ https://status.npmjs.org/ I love fake status pages!
- wxuan 8y ago
  Overall, the system is up and running. I believe, the issue only affects a subset of users behind proxies.
  - iends 8y ago
    This is exactly what a status page should communicate.
  - gpvos 8y ago
    Then put it on yellow or something.
    - TeMPOraL 8y ago
      And ruin the marketing value of long history of status page showing green? I feel some companies have the following meaning for the lights: yellow is when servers are literally on fire. Red is when the CEO is bleeding out somewhere on the floor, and the Feds are about to bust in and close the shop.
      - ReidZB 8y ago
        AWS certainly operates that way, but even with a third level: green check mark with an info note box. I think I've only seen a "red" AWS status once or twice in the past few years. Before AWS updated their status page to be a little more usable, I used a Chrome extension to remove green status services from the page. Funny enough, that extension also incremented every status (info check box became warning, warning became red), which was far more accurate in my experience.
      - noir_lord 8y ago
        For red can we just call that a Cambridge Analytica?
olingern 8y ago
Here's to hoping that all my yarn caches will continue to carry me through this. Seriously, though. I'd love to get a look at their SLA and how they define "uptime" for their "org" and "enterprise" users. I don't think most teams are running out the door to throw their money at npm, and it's this type of instability that creates mistrust amongst developers.
- spondyl 8y ago
  Yarn seems to be unaffected with this issue so I imagine you'll be fine. There's been a few users (including myself) who simply swapped out npm for yarn and have had the issue resolved. It doesn't really address the root cause but in this case, it's presumably some bit of logic in the actual npm client itself rather than the registry.
  - olingern 8y ago
    Last time I checked the yarnpkg registry is still a proxy to npm, unless they've started hosting. I haven't checked in some time.
    - fold_left 8y ago
      You're right
    - lnanek2 8y ago
      yarn is basically an npm wrapper that add caching, so even so, it's good for avoiding intermittent errors
symlinkk 8y ago
It’s appalling how bad the NPM development team is. Do they have any sort of test suite at all? I’m switching to Yarn.
- ulkesh 8y ago
  I’m reminded of when npm was beginning to get popular and all the web devs I worked near were acting like it was pure gold and the first of its kind; as if other package managers like maven or apt never existed. These days I just have to laugh and shake my head.
hbcondo714 8y ago
> The HTTP 418 I'm a teapot client error response code indicates that the server refuses to brew coffee because it is a teapot. This error is a reference of Hyper Text Coffee Pot Control Protocol which was an April Fools' joke in 1998. https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/418 https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/418
- nielsbot 8y ago
  yeah but, no but...
stevebmark 8y ago
Why connect to npm through a proxy?
- thejosh 8y ago
  Enterprise users or people in offices?
- ulkesh 8y ago
  - To cache - To have your own repo since npm doesn’t support composite repos like Maven (last I checked) - To not trust that npm won’t take a dump like today - To not let npm know your IP address of your dev boxes or build boxes I’m sure there are many more reasons...
- marksomnian 8y ago
  Because corporate won't let you connect without one.
notacuck 8y ago
I'm going to cancel my paid subscription and remove my private packages. npm's incompetence has been a joke for years and it's a real shame they're propped up so highly by Node.
- yeukhon 8y ago
  Better choice: move away from Node.
flavio81 8y ago
- Obligatory reminder that the NPM system is a failboat. - Public Service Announcement: Don't board the failboat.
- bartread 8y ago
  Thanks, but what's the alternative when yarn relies on npm infrastructure? Like it or not, you're still using npm. It's got so you basically cannot do serious client-side development without one of them.
  - mykull 8y ago
    "Enterprise development" is not the same as "serious development". Anyone still doing regular old JavaScript without the transpiling and megaframework dependencies is arguably taking their task more seriously than those who are.
    - bartread 8y ago
      Who's talking about transpiling and mega-frameworks? I'm simply talking about the headache of managing dependencies on a reasonably complex project. The "mega-frameworks", by which I assume you mean products such as Angular, React, Vue, etc., are often not the worst offenders when it comes to external dependencies. Of course, when you start pulling in extensions that story can change, but that can be true of pulling in any other library that provides equivalent functionality (where such exists).
    - moogly 8y ago
      I'm sorry, but after having used TypeScript there's no way I'm ever going to back to writing pure JavaScript anymore (for anything but the most trivial stuff). It's borderline irresponsible, IMO.
      - mykull 8y ago
        I'd like to say I love typescript, too. It's better for collaborative development than raw JS. My point is different, that working in the "low level" or raw JS, obfuscated or not, is where the substantive work happens. Good example is the people working on frameworks.
stevenjohns 8y ago
Just been fixed, apparently[0]: > We've fixed this -- we now accept the port appended to the host. @wgrant's comment was most helpful, thank you! [0] https://github.com/npm/npm/issues/20791#issuecomment-392648459 https://github.com/npm/npm/issues/20791#issuecomment-3926484...
- nneonneo 8y ago
  They did fix it, but e.g. appending a period (https://registry.npmjs.org./ https://registry.npmjs.org./) still throws a 418 - I expect this to bite them someday (eventually). I don't understand why their Host: parsing is so strict; it seems unnecessarily restrictive.
  - gpvos 8y ago
    418 is really a confusing response here. They should fix that ASAP by giving a normal error message.
    - nneonneo 8y ago
      I would recommend (if any NPM people are reading this) that the error for an unknown Host header be changed to 404. Bad host headers are already filtered out by Cloudflare (which returns 400), so any host headers that make it through would represent "unknown"/"missing" hosts (hence 404).
- ulkesh 8y ago
  With no explanation about it being a 418. Par for the course, I suppose.
xab9 8y ago
Okay, I appreciate npm and everything, but nowdays new versions come out on a weekly basis yet something still breaks, either locally or in the CI for us. This made me fear two things the most lately: `npm i` and `npm i -g npm`.
Jaruzel 8y ago
What makes me sad, is that this error (caused by the mis-use of the 418 status code) and a previous issue (I forget the link) where a web dev was complaining that 'I'm a teapot' was stupid and should be pulled from the specs, will result in 418 being removed from the standard, and the humourless suits win again. If we can't have a little bit of levity in our lives, then what's the point of it all ?
- mseebach 8y ago
  > the humourless suits win again I think this is misguided. Clearly, there are plenty of humourless prudes, even amongst Us, the Blessed T-shirt Wearers. To wit, the "campaign" to remove the 418 code did not originate in a corner office.
  - coldtea 8y ago
    Being a "suit" is a state of mind, not an article of clothing.
    - sundarurfriend 8y ago
      "Hey man, I'm not a suit." "Yeah you are, you just don't know it yet." (Entourage, https://youtu.be/E-v1hOJCphI?t=78 https://youtu.be/E-v1hOJCphI?t=78 (NSFW video))
- C14L 8y ago
  Yeah well, if they do that, we'll make our own internet, with blackjack, and teapots!
JazzXP 8y ago
I'm wondering if returning 418 is some sort of "off by one" error. Maybe their list of error codes are in an array, meant to send 500, but picked n-1 falling on 418?
partycoder 8y ago
This HN comment is probably one of the best explanations of why npm can be objectively said to be unreliable. I think it deserves attention. https://news.ycombinator.com/item?id=17176486 https://news.ycombinator.com/item?id=17176486
anonnyj 8y ago
// This code will never execute
skywhopper 8y ago
They say they've fixed this in this related issue (https://github.com/npm/registry/issues/335 https://github.com/npm/registry/issues/335) but I can't tell what change was made. The only discussion was around accepting a port number in the Host header. All well and good to fix what I assume was a config bug. But I can't tell if the secondary (but arguably more important) issue of returning valid error messages was addressed. I'm not sure what the exact right error message should have been. If the server was intentionally differentiating host headers with port numbers then probably 400 or possibly 404. But I'm guessing this was just a plain and simple bug and that 418 was set as a cutesy catchall "something unexpected happened" error status to be sent in some exception condition. I hope they've changed that to return 500, which would at least honestly accept blame for the issue.
- pluma 8y ago
  I'm guessing they used 418 to mean "I have no idea who you think you're talking to" (not entirely unfitting as 418 was proposed to indicate the coffee pot you're talking to is actually a tea pot), considering it was triggered by having the Host set to something it did not recognise. But they should still have used a real error code and a more informative message.

294 points by spondyl 8y ago

Relevant comment by wgrant: The body of the 418 is {"error":"got unknown host (registry.npmjs.org:443)"}. Looks like some npm clients are appending the port to the Host header, but only when going through a proxy, and that's confusing the registry. It seems to be based on combination of npm:node version.

hn_throwaway_99 8y ago
Sure, but why is anything in the chain returning the 418 "I'm a teapot" error message? My guess is someone wanted to use some code for "I don't really know what this error is", saw the 418 and thought "that's cute!" Be careful, "cuteness" and "cleverness" has a way of biting you in the behind.
- hluska 8y ago
  Ha! I used to use 418 as my "everything is completely fucked and there's no way everything will ever get that fucked, so this is the best code possible" status code. It took about a year for me to internalize that things will often be that fucked. :)
  - simplecomplex 8y ago
    500 “Internal Server Error” is the code you should be using for generic server errors.
    - 49bc 8y ago
      Yes a 500. Not sure how anything else would ever pass the smell test of even a lazy pull request.
    - curun1r 8y ago
      It's important to say why that's the correct error code. In this case, it's because 5xx errors can be retried in the future whereas 4xx errors tell the client that any retries will receive the same response.
      - eropple 8y ago
        This is honored more in the breach than the observance at times, though, particularly with 404.
      - boomlinde 8y ago
        In general, this is wrong. 4xx status may be retried, achieving different results each time. This makes sense with for example status 409 and 429, where this is definitely expected, or 404 since resources may be added or removed at any time independent of any single client, or 402 and 403 which may change out of band. Conversely, there are 5xx statuses that you shouldn't expect to change with each request, for example 505 (HTTP version not supported) or, really, 500 in some cases. There's AFAIK no standardized strategy to deal with the different status code. Instead it's important to get the status code right to as accurately as possible describe the error to the client. The server never tells the client what to do; it tells it what went wrong so that the client can deal with the error at its own discretion. In this case the server told he client that it was a teapot when what actually happened was an internal server error. That's wrong because it's wrong, not because every client will or even should deal with either of these errors in a predictable way.
        curun1r 8y ago
        > There's AFAIK no standardized strategy to deal with the different status code While I was a bit too over-broad in my generalizations of 4xx vs 5xx status codes when it comes to retries, the gist is still the same. The specification does specifically call out when it's okay to retry and when it isn't. And it also specifically calls out when it's okay for intermediate servers and browsers to cache responses and when it isn't. In the case being discussed, 500 is specifically the correct error code because it cannot be cached and can be retried. That's not the case for 409 or 429, which either cannot be retried automatically (409) or can be cached (429). 402 is, IIRC, underspecified and shouldn't be used. 403 specifically states that the request should not be retried. It's important to make a distinction between the user/application and the user agent when we talk about retries. The user agent is the program or library that implements the HTTP spec. You seem to be talking about the former, who is always capable of retrying a request when they feel circumstances have changed enough for the request to succeed. But user agents are intentionally dumber. They can't resolve conflicts, fix permissions or do anything outside of the logic dictated by the spec. And they have much more limited license to retry 4xx responses or cache 5xx responses.
    - yeukhon 8y ago
      Actually, 503 is better in this case. Internally it shlkld report 500.
    - hluska 8y ago
      I'm sorry that I wasn't more clear. The person I was replying to aptly wrote "'cuteness' and 'cleverness' has a way of biting you in the behind", and I was agreeing with/adding to that comment. I've been guilty of cleverness and sure enough, it has usually found a way to get me in the end. Today, in similar situations, I'd return a 500 with a message in the body.
    - sofaofthedamned 8y ago
      I've seen the teapot error used when the internal route of a request was circuitous (many servers involved) and a 500 could have come form anywhere. It was used as a canary, and only on this codebase which was bought-in and absolutely awful.
    - K0nserv 8y ago
      No it's not since this is a error on the client's side it should be a 4xx code, probably not 418 though.
  - astura 8y ago
    500 is the correct error code to use in that case.
  - jmvoodoo 8y ago
    It's 4xx so it should be used only to represent an issue with the request/client, not the server :)
- nmjohn 8y ago
  > Be careful, "cuteness" and "cleverness" has a way of biting you in the behind. Generally speaking I tend to agree, but in this specific case how is sending a 418 "biting you in the behind" worse than sending a more proper 500 error? (Or perhaps a 400? Hard to say exactly, feels like the server is having unexpected errors since it cannot properly parse the hostname.)
  - reificator 8y ago
    If I'm doing quick generic error handling, I'm going to assume anything in the 500 range is a server issue and display an error of the sort. If it's in the 400 range I'm going to handle the common ones and then assume it's the client's or user's fault. (And of course a user fault is really a client validation fault.) So yes, returning a 4XX for a 5XX is problematic.
    - nmjohn 8y ago
      But is that relevant to _this specific_ case? The problem is not 3rd party clients, it's the npm client itself - so I don't know how error handling is relevant? (In the general case, yes of course it is, but in this and the parent comment I'm specifically talking about issues in only the narrow use case here.)
      - reificator 8y ago
        Being first party doesn't mean it's the same person/team writing both sides. And error handling is always relevant.
      - tedivm 8y ago
        The error was on the server side, not the client side. The server was not following the HTTP spec. The fact that it was server side was why they were able to fix this so quickly. Since it was a server side error, and the issue was not a client side one, the 500 error code is most appropriate. The fact that the npm client itself is the first one to trigger this error is not the issue here, as it could have just as easily been yarn or another client. Following standards are important, and we weren't trying to make tea.
- nneonneo 8y ago
  The origin server (registry.npmjs.org) is the one throwing the 418, so they're primarily to blame. Some intermediate proxy server has decided to send a somewhat unusual Host header (registry.npmjs.org:443 instead of the usual registry.npmjs.org), and the registry server barfs up a 418 in response.
- jwalton 8y ago
  As per https://tools.ietf.org/html/rfc2324 https://tools.ietf.org/html/rfc2324, the server is throwing 418 because it is a teapot, and can't brew coffee. Perhaps this is a coffeescript related problem.
  - fyfy18 8y ago
    I’m not sure if this is really compliant to that spec either. It states that error code should be returned when attempting to brew coffee - which means the BREW or POST method is used - but this is using the GET method.
    - stephengillie 8y ago
      Has a BREW call been used? The spec might not support out of order operations. That should be tried before any further GET attempts against the coffee interface.
- rejschaap 8y ago
  > Sure, but why is anything in the chain returning the 418 "I'm a teapot" error message? My best guess? The request ended up at a teapot and the poor thing was asked to do something that no teapot has ever done before.
- nonconvergent 8y ago
  There's nothing clever about returning the wrong error. That's anti-clever.
nneonneo 8y ago
Can confirm: $ curl -vvv -H 'Host: registry.npmjs.org:443' https://registry.npmjs.org:443 > GET / HTTP/1.1 > Host: registry.npmjs.org:443 > User-Agent: curl/7.54.0 > Accept: */* > < HTTP/1.1 418 I'm a teapot < Date: Tue, 29 May 2018 03:52:16 GMT < Content-Type: text/plain;charset=UTF-8 < Content-Length: 53 < Connection: keep-alive < Set-Cookie: __cfduid=d3f8dd8d2121ede348194ee142443bccc1527565936; expires=Wed, 29-May-19 03:52:16 GMT; path=/; domain=.registry.npmjs.org; HttpOnly; Secure < Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct" < Server: cloudflare < CF-RAY: 422601de4bf49fc6-IAD < {"error":"got unknown host (registry.npmjs.org:443)"} Per RFC 7230, §5.4 (https://tools.ietf.org/html/rfc7230#section-5.4 https://tools.ietf.org/html/rfc7230#section-5.4), the port is optional if it's the default for the URI (:80 for http, :443 for https), but nowhere in the spec does it say it's an error to include a redundant port specifier. The registry server is likely noncompliant here, and it definitely should not be throwing 418 here. (400 would be appropriate if the Host header was malformed - but that's not even the case here).

kasey_junk 8y ago

Comments about the error not being helpful! Presumably the npm community is full of web devs. Given that how can they not know the http codes, especially one as famous as 418?

sk5t 8y ago
I'd argue that 418 veers more towards "trivial" than it does "famous." Expecting knowledge of more than 400, 401, 403, 404, and maybe 412 is pushing it.
whatsstolat 8y ago
I didn't know 418 and I'm a web dev. Http status codes are a tiny part of my job
- 49bc 8y ago
  Not only that, but if you’re returning this status code you’re almost certainly doing something wrong or user hostile.
  - matte_black 8y ago
    What if it really is a teapot? Not that farfetched with today's internet connected devices.
    - hedora 8y ago
      There’s the EKG+, an internet connected smart kettle: http://fellowproducts.com/shop/staggekg/ http://fellowproducts.com/shop/staggekg/ I have the plain EKG, and quite like it. However, both are designed for pour-over coffee, so can’t correctly return 418.
    - deleted 8y ago
      [deleted]
    - 49bc 8y ago
      I still don't think returning a 418 (in the realm of client errors) is the correct code, even if it is a connected teapot which you're trying to identify! I think the appropriate action would be a client sends an HTTP HEAD to the service, which responds 200 "TEAPOT".

vorpalhex 8y ago

Really disappointed in NPM lately. These past few months have been downright silly. How many major problems like this affect other package managers?

swyx 8y ago
what else in these "past few months" are you referring to? as a moderate npm user i am blissfully oblivious.
- losingthefight 8y ago
  Not OP but maybe he is referring to the big in which the npm upgrade bumped to a non-ready version and caused havoc on production systems by overwriting permissions and files: https://github.com/npm/npm/issues/19883 https://github.com/npm/npm/issues/19883 That was the end of February, so not sure but that may be it.
  - jjeaff 8y ago
    There was also the issue where npm filter bots accidentally expelled some large, legitimate users and then made the namespace available, thus allowing random people to take the packages over, and inject code into any applications that used those projects.
    - erichurkman 8y ago
      This is one of the scariest aspects to modern development. Thousands of applications are one bad actor away from ruin. We're incredibly vulnerable. Chrome extension gone rogue? Package repository allowed duplicate packages? A contributor's GitHub key was hijacked? Imagine uBlock Origin's Chrome extension author creds were hacked. "He" publishes a new version of the Chrome extension that monitors coinbase.com and fakes the transfer/confirmation screen, or submits transfers in the background. The extension has "write" access on all sites, so the rogue extension can also monitor your Gmail and silently inject a filter that routes trade confirmations to trash. Or the "requests" library in Python gets an update to replicate 2FA codes via Twilio to a 3rd party. Sure, you can do pinning and cryptographic signatures to verify that v 1.0.0 of X is really what you expected. But who audited 1.0.0 of X in the first place...?

danschumann 8y ago

The last comment is locking the issue because too many people are responding saying the same thing. This comment makes me want to reply and say the same thing too, but I can't now.

freditup 8y ago
Locking a discussion with zero-unreasonable responses as "too heated" is bad optics, but I think locking the discussion is a pragmatic decision, as the NPM team has been alerted about the issue and any meaningful comments would get lost in the noise otherwise.
- stonogo 8y ago
  Instead, they're just regular lost. Not much of an improvement.
- phyzome 8y ago
  It's likely that the "too heated" is GitHub putting words in the mouth of the repo admins. I don't think you get to choose the text of that message. ETA: The options are "off-topic", "too heated", "resolved" and "spam". It looks like you can also elect to not give a reason, though...
- gpvos 8y ago
  One of the last few messages before that, by wgrant, was helpful in solving the problem. They might have missed that if they had closed the thread a little bit earlier.
thsowers 8y ago
I think this is one reason GitHub rolled out the "thumbs-up" reactions, too many comments just state "+1", which pollutes actual technical discussion, but at the same time it is crucial to know if many people have the same issue
yeukhon 8y ago
If they are annoyed by the spam, they can “mute”.

minikomi 8y ago

Perhaps it really is a teapot.

itgoon 8y ago
It isn't being asked to brew coffee, though, so it's a mis-use of the spec.
- d4n1elchen 8y ago
  Or maybe you're asking a teapot to install npm packages.
duxup 8y ago
Maybe we all are...
- Mithorium 8y ago
  we are ALL teapots on this blessed day :)

Abishek_Muthian 8y ago

A moment of sympathy for the engineers who have to explain their non technical project manager on why their application is getting this error.

rdtsc 8y ago
I learned my lesson not put cutesey messages in the logs the hard way. I was young and dumb and in my case it was for a restore from backup system. A customer had failed hardware and was trying to restore from backup. It was failing and the funny message all of the sudden didn't sound too funny when customer was reading it back to me in their own voice over the phone.
- DrJokepu 8y ago
  Oh I’ve done that too as a rookie. Software displayed an error message when the application was in a state that was impossible for it to be in, at least in theory. The error message was a line from 2001 Space Odyssey: “I’m sorry Dave, I’m afraid I can’t let you do that”. Of course when it ended up getting displayed it was displayed to a customer called Dave who has never seen (or read) 2001 Space Odyssey. The first lesson was to avoid funny error messages in the future. The other was that “impossible” things tend to happen surprisingly frequently in software.
  - DoreenMichele 8y ago
    With 7 billion people on the planet, one in a million events are guaranteed to happen to about 7k people. Law of stats of large numbers etc
    - zitterbewegung 8y ago
      More like birthday theorem applies here .
    - mlyle 8y ago
      There's a lot of different possible 1 in a million events, though...

deleted 8y ago

[deleted]

purephase 8y ago

My favourite HTTP response...

donpdonp 8y ago
https://http.cat/418 https://http.cat/418

forapurpose 8y ago

It actually reads like an IoT protocol, way ahead of its time in 1998. Life not only imitates art, but eventually catches up with parody: https://tools.ietf.org/html/rfc2324 https://tools.ietf.org/html/rfc2324

FroshKiller 8y ago
I suspect the joke was inspired in part by a certain well known coffee pot monitoring system that preceded it: https://en.wikipedia.org/wiki/Trojan_Room_coffee_pot https://en.wikipedia.org/wiki/Trojan_Room_coffee_pot

incadenza 8y ago

I’m sure the anti-NPM brigade is on its way, but I recall there being a huge backlash against removing this error code from Node a few years ago.

pluma 8y ago
The problem isn't that Node supports this error code. The problem is that it's used by the registry. Heck, technically the problem isn't even that it's used by the registry, the problem is the npm client is a broken untestable mess and users seem to routinely unearth extremely surprising bugs. This all has very little to do with teapots. The fact they used 418 and didn't provide a useful error message only makes it more interesting to talk about.
- incadenza 8y ago
  Yeah, fair point.

btown 8y ago

Is it too soon to call this Teapotgate?

jugg1es 8y ago
It's 'too soon' until the water is boiling. Then it's 'tea time'.
hartator 8y ago
It’s tea soon.
deleted 8y ago
[deleted]
gtremper 8y ago
Teapot Dome

umurkontaci 8y ago

> I'm gonna lock this for now, because I'm sure it's gonna get plenty of traffic. You really don't need to respond to repeat what every other poster is saying. The registry team has been informed. It's alright if they want to lock the thread to prevent a massive +1 spam, but at the very least they should have given a link to track the status of this. When your production systems are down, "thanks for the report" is not a good enough response.

olingern 8y ago
Something more along the lines of: > Thanks so much for the report. Currently, we are doing the best to resolve the issue. Please continue to check back on our status page to see our updates. https://status.npmjs.org/ https://status.npmjs.org/ Sounds more appropriate
ludston 8y ago
Isn't it? I would rather get an update after the problem has been fixed than to know that development efforts have been slowed down in order to keep me in the loop. I am not sure if you are putting your money where your mouth is. This product can be used for free, and there is a simple work around. (i.e. Test before you upgrade.)
- yegle 8y ago
  https://cloudplatform.googleblog.com/2017/02/Incident-management-at-Google-adventures-in-SRE-land.html https://cloudplatform.googleblog.com/2017/02/Incident-manage... is a good article re how Google handles incident. In an incident, constant and clear communication is a key.
  - ludston 8y ago
    Different scope. This is definitely how to handle incidents like, "our live production service is currently having issues" because there are critical consequences. e.g. When a system that I have worked on goes down, trucks would literally be parked at the border of different states and countries waiting for clearance. This is a different magnitude to, "I upgraded my free dependency management tool, and now I have to downgrade it. Please tell me when I can upgrade again."

iends 8y ago

2 hours after the incident was responded to by an npm employee and the status is still green: https://status.npmjs.org/ https://status.npmjs.org/ I love fake status pages!

wxuan 8y ago
Overall, the system is up and running. I believe, the issue only affects a subset of users behind proxies.
- iends 8y ago
  This is exactly what a status page should communicate.
- gpvos 8y ago
  Then put it on yellow or something.
  - TeMPOraL 8y ago
    And ruin the marketing value of long history of status page showing green? I feel some companies have the following meaning for the lights: yellow is when servers are literally on fire. Red is when the CEO is bleeding out somewhere on the floor, and the Feds are about to bust in and close the shop.
    - ReidZB 8y ago
      AWS certainly operates that way, but even with a third level: green check mark with an info note box. I think I've only seen a "red" AWS status once or twice in the past few years. Before AWS updated their status page to be a little more usable, I used a Chrome extension to remove green status services from the page. Funny enough, that extension also incremented every status (info check box became warning, warning became red), which was far more accurate in my experience.
    - noir_lord 8y ago
      For red can we just call that a Cambridge Analytica?

olingern 8y ago

Here's to hoping that all my yarn caches will continue to carry me through this. Seriously, though. I'd love to get a look at their SLA and how they define "uptime" for their "org" and "enterprise" users. I don't think most teams are running out the door to throw their money at npm, and it's this type of instability that creates mistrust amongst developers.

spondyl 8y ago
Yarn seems to be unaffected with this issue so I imagine you'll be fine. There's been a few users (including myself) who simply swapped out npm for yarn and have had the issue resolved. It doesn't really address the root cause but in this case, it's presumably some bit of logic in the actual npm client itself rather than the registry.
- olingern 8y ago
  Last time I checked the yarnpkg registry is still a proxy to npm, unless they've started hosting. I haven't checked in some time.
  - fold_left 8y ago
    You're right
  - lnanek2 8y ago
    yarn is basically an npm wrapper that add caching, so even so, it's good for avoiding intermittent errors

symlinkk 8y ago

It’s appalling how bad the NPM development team is. Do they have any sort of test suite at all? I’m switching to Yarn.

ulkesh 8y ago
I’m reminded of when npm was beginning to get popular and all the web devs I worked near were acting like it was pure gold and the first of its kind; as if other package managers like maven or apt never existed. These days I just have to laugh and shake my head.

hbcondo714 8y ago

> The HTTP 418 I'm a teapot client error response code indicates that the server refuses to brew coffee because it is a teapot. This error is a reference of Hyper Text Coffee Pot Control Protocol which was an April Fools' joke in 1998. https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/418 https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/418

nielsbot 8y ago
yeah but, no but...

stevebmark 8y ago

Why connect to npm through a proxy?

thejosh 8y ago
Enterprise users or people in offices?
ulkesh 8y ago
- To cache - To have your own repo since npm doesn’t support composite repos like Maven (last I checked) - To not trust that npm won’t take a dump like today - To not let npm know your IP address of your dev boxes or build boxes I’m sure there are many more reasons...
marksomnian 8y ago
Because corporate won't let you connect without one.

notacuck 8y ago

I'm going to cancel my paid subscription and remove my private packages. npm's incompetence has been a joke for years and it's a real shame they're propped up so highly by Node.

yeukhon 8y ago
Better choice: move away from Node.

flavio81 8y ago

- Obligatory reminder that the NPM system is a failboat. - Public Service Announcement: Don't board the failboat.

bartread 8y ago
Thanks, but what's the alternative when yarn relies on npm infrastructure? Like it or not, you're still using npm. It's got so you basically cannot do serious client-side development without one of them.
- mykull 8y ago
  "Enterprise development" is not the same as "serious development". Anyone still doing regular old JavaScript without the transpiling and megaframework dependencies is arguably taking their task more seriously than those who are.
  - bartread 8y ago
    Who's talking about transpiling and mega-frameworks? I'm simply talking about the headache of managing dependencies on a reasonably complex project. The "mega-frameworks", by which I assume you mean products such as Angular, React, Vue, etc., are often not the worst offenders when it comes to external dependencies. Of course, when you start pulling in extensions that story can change, but that can be true of pulling in any other library that provides equivalent functionality (where such exists).
  - moogly 8y ago
    I'm sorry, but after having used TypeScript there's no way I'm ever going to back to writing pure JavaScript anymore (for anything but the most trivial stuff). It's borderline irresponsible, IMO.
    - mykull 8y ago
      I'd like to say I love typescript, too. It's better for collaborative development than raw JS. My point is different, that working in the "low level" or raw JS, obfuscated or not, is where the substantive work happens. Good example is the people working on frameworks.

stevenjohns 8y ago

Just been fixed, apparently[0]: > We've fixed this -- we now accept the port appended to the host. @wgrant's comment was most helpful, thank you! [0] https://github.com/npm/npm/issues/20791#issuecomment-392648459 https://github.com/npm/npm/issues/20791#issuecomment-3926484...

nneonneo 8y ago
They did fix it, but e.g. appending a period (https://registry.npmjs.org./ https://registry.npmjs.org./) still throws a 418 - I expect this to bite them someday (eventually). I don't understand why their Host: parsing is so strict; it seems unnecessarily restrictive.
- gpvos 8y ago
  418 is really a confusing response here. They should fix that ASAP by giving a normal error message.
  - nneonneo 8y ago
    I would recommend (if any NPM people are reading this) that the error for an unknown Host header be changed to 404. Bad host headers are already filtered out by Cloudflare (which returns 400), so any host headers that make it through would represent "unknown"/"missing" hosts (hence 404).
ulkesh 8y ago
With no explanation about it being a 418. Par for the course, I suppose.

xab9 8y ago

Okay, I appreciate npm and everything, but nowdays new versions come out on a weekly basis yet something still breaks, either locally or in the CI for us. This made me fear two things the most lately: `npm i` and `npm i -g npm`.

Jaruzel 8y ago

What makes me sad, is that this error (caused by the mis-use of the 418 status code) and a previous issue (I forget the link) where a web dev was complaining that 'I'm a teapot' was stupid and should be pulled from the specs, will result in 418 being removed from the standard, and the humourless suits win again. If we can't have a little bit of levity in our lives, then what's the point of it all ?

mseebach 8y ago
> the humourless suits win again I think this is misguided. Clearly, there are plenty of humourless prudes, even amongst Us, the Blessed T-shirt Wearers. To wit, the "campaign" to remove the 418 code did not originate in a corner office.
- coldtea 8y ago
  Being a "suit" is a state of mind, not an article of clothing.
  - sundarurfriend 8y ago
    "Hey man, I'm not a suit." "Yeah you are, you just don't know it yet." (Entourage, https://youtu.be/E-v1hOJCphI?t=78 https://youtu.be/E-v1hOJCphI?t=78 (NSFW video))
C14L 8y ago
Yeah well, if they do that, we'll make our own internet, with blackjack, and teapots!

JazzXP 8y ago

I'm wondering if returning 418 is some sort of "off by one" error. Maybe their list of error codes are in an array, meant to send 500, but picked n-1 falling on 418?

partycoder 8y ago

This HN comment is probably one of the best explanations of why npm can be objectively said to be unreliable. I think it deserves attention. https://news.ycombinator.com/item?id=17176486 https://news.ycombinator.com/item?id=17176486

anonnyj 8y ago

// This code will never execute

skywhopper 8y ago

They say they've fixed this in this related issue (https://github.com/npm/registry/issues/335 https://github.com/npm/registry/issues/335) but I can't tell what change was made. The only discussion was around accepting a port number in the Host header. All well and good to fix what I assume was a config bug. But I can't tell if the secondary (but arguably more important) issue of returning valid error messages was addressed. I'm not sure what the exact right error message should have been. If the server was intentionally differentiating host headers with port numbers then probably 400 or possibly 404. But I'm guessing this was just a plain and simple bug and that 418 was set as a cutesy catchall "something unexpected happened" error status to be sent in some exception condition. I hope they've changed that to return 500, which would at least honestly accept blame for the issue.

pluma 8y ago
I'm guessing they used 418 to mean "I have no idea who you think you're talking to" (not entirely unfitting as 418 was proposed to indicate the coffee pot you're talking to is actually a tea pot), considering it was triggered by having the Host set to something it did not recognise. But they should still have used a real error code and a more informative message.