5 ms·

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

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

by tiles 8y ago

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