First, the HTTP spec _mandates_ that a port number be appended when it is not the default, so a server has to accept it. Not a client issue at all. It was fixed on their service, not the clients.
Second, the service should respond with 400, not a funny 418 when it fails to parse the host field. This is also a bug on their end.
Finally, where does payment come into play? Does anybody expect bugs in homebrew / yum / aptitude / rubygems to go unfixed because those are not paid services?
Merely commenting on the word customers: npm has few customers but a lot of users.
> Second, the service should respond with 400, not a funny 418 when it fails to parse the host field. This is also a bug on their end.
Is it a bug that on error youtube serves a 200OK page that says that "A team of highly trained monkeys has been dispatched" when their is an actual error? [EDIT: they are since returning 500 errors now, not 200 anymore, though they did do this in the past]. Note that 418 is an actual HTTP status code, for all we know the server was actually a tea pot . If this is the case is it not a bug anymore?
> First, the HTTP spec _mandates_ that a port number be appended when it is not the default, so a server has to accept it. Not a client issue at all. It was fixed on their service, not the clients.
This has little to do with the status page. Yes it's not formal against the HTTP spec if NPM does this but if you want to cover that you need tests of the sort that will validate output against a spec, NOT a status page that is meant for an entirely different purpose (to indicate whether your service is down or not).
Second, the service should respond with 400, not a funny 418 when it fails to parse the host field. This is also a bug on their end.
Finally, where does payment come into play? Does anybody expect bugs in homebrew / yum / aptitude / rubygems to go unfixed because those are not paid services?