3 ms·
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
by 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 agoBut 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 agoBeing first party doesn't mean it's the same person/team writing both sides. And error handling is always relevant.
- tedivm 8y agoThe 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.