3 ms·

> 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

by 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.
TheDong 8y ago
In general, proxies and other third party clients will consider 4xx errors (edit: un)retriable. That's one simple obvious difference.
- reificator 8y ago
  Do you mean 5XX? 4XX errors generally cannot be retried with a different result.
boomlinde 8y ago
> Or perhaps a 400? Well ideally some 5xx code because it's a server error. I personally think servers should default to 500 if there is an uncaught or unhandled error condition.
- deleted 8y ago
  [deleted]
nonconvergent 8y ago
The type of status/error matters. It's how your communicate, server to client. Think about your normal interactions with problem solving as a team. What's more useful, a teammate who tells you when there's a problem what the problem is or a teammate who hides things, obfuscates, and makes random jokes? 400 tells you asked in a way that wasn't understood. 401 says you're unauthorized and 403 says you're not allowed (similar but potentially different implications, not my favorite nuance but it's a common example that might come up) 504 says there's a problem communicating between the two of you. 404 says that your data doesn't exist. 500 says the server is having problems doing the thing and it's completely out of your hands. 418 says "I'm a teapot" What's more useful data?

by nmjohn 8y ago

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.

TheDong 8y ago

In general, proxies and other third party clients will consider 4xx errors (edit: un)retriable. That's one simple obvious difference.

reificator 8y ago
Do you mean 5XX? 4XX errors generally cannot be retried with a different result.

boomlinde 8y ago

> Or perhaps a 400? Well ideally some 5xx code because it's a server error. I personally think servers should default to 500 if there is an uncaught or unhandled error condition.

deleted 8y ago
[deleted]

nonconvergent 8y ago

The type of status/error matters. It's how your communicate, server to client. Think about your normal interactions with problem solving as a team. What's more useful, a teammate who tells you when there's a problem what the problem is or a teammate who hides things, obfuscates, and makes random jokes? 400 tells you asked in a way that wasn't understood. 401 says you're unauthorized and 403 says you're not allowed (similar but potentially different implications, not my favorite nuance but it's a common example that might come up) 504 says there's a problem communicating between the two of you. 404 says that your data doesn't exist. 500 says the server is having problems doing the thing and it's completely out of your hands. 418 says "I'm a teapot" What's more useful data?