4 ms·

Yes, that status page is only for the registry. This error was in how clients were appending ports to the HOST header.

iends 8y ago
This seems like playing semantics rather than focusing on what your customers care about...especially since the issue was fixed on the server.
- askmike 8y ago
  The status page doesn't display what customers care about. It displays whether the servers are up and reachable. If this effected everyone I see your point, but it didn't. Note that most NPM "customers" don't pay a dime.
  - ricardobeat 8y ago
    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?
    - askmike 8y ago
      > Finally, where does payment come into play? 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).
      - deleted 8y ago
        [deleted]
  - iends 8y ago
    The status page should be used for conveying more than just "whether the servers are up and reachable" and it's obvious that npm thinks so too. At the top of their page they list an issue about certain packages that "are currently unable to be viewed or installed." If you're using your status page just to talk about sever availability and not about all types of service interruptions then you're not taking advantage of arguably the most important communication channel your customers care about. In the end, you'll break their trust and you'll have to work impossibly hard to get it back.

This seems like playing semantics rather than focusing on what your customers care about...especially since the issue was fixed on the server.

askmike 8y ago
The status page doesn't display what customers care about. It displays whether the servers are up and reachable. If this effected everyone I see your point, but it didn't. Note that most NPM "customers" don't pay a dime.
- ricardobeat 8y ago
  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?
  - askmike 8y ago
    > Finally, where does payment come into play? 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).
    - deleted 8y ago
      [deleted]
- iends 8y ago
  The status page should be used for conveying more than just "whether the servers are up and reachable" and it's obvious that npm thinks so too. At the top of their page they list an issue about certain packages that "are currently unable to be viewed or installed." If you're using your status page just to talk about sever availability and not about all types of service interruptions then you're not taking advantage of arguably the most important communication channel your customers care about. In the end, you'll break their trust and you'll have to work impossibly hard to get it back.