registry unconditionally returning gzipped JSON responses breaks old npm #12196
Comments
|
some one can help me? |
|
Seeing similar issues right now for other packages as well. |
|
It seems I was using a rather old version of npm. Upgrading to much more recent npm (v3.8.5) makes things run more smoothly. |
|
Seeing lots of the same errors today, updating npm/node resolves - did something change on the endpoints to render the old versions non-functional? |
|
we're seeing the same problems with npm 1.3.14. is updating npm the only solution? |
|
We're running node 0.10.21 and npm 1.3.11 on CentOS and are experiencing the same issues. We're not that able to update node at the moment, has anyone found a solution which doesn't require updating node? btw this is happening for all my required npm modules, not specifically localtunnel. |
|
you can update npm without updating node via |
|
@p0wl you cant if your npm as old as the ubuntu-14.01 default package :( |
|
We have same problem, npm 1.3.10 and node 0.10.25. Can't currently upgrade the npm globally. Our current workaround is to install newer npm via the old one locally, ie. And then use it to install other dependencies |
|
@npm/registry-team team is testing a switch over to The registry team is in the process of rolling back this change until we can try again with a safer combination of headers that won't break old npm. I would also strongly urge anyone and everyone running Thanks for your time and the detailed reports, everyone. I'll close this once we've rolled back the changes to the registry and given the CDN cache time to invalidate. |
|
I was on NPM 3.3.6 and Node 5.0 and getting these issues |
|
@kelsmj Can you upload the console output to https://gist.github.com/? I suspect that your node process may be running a subprocess that's a Node of an older version, because by default |
|
It was actually JSPM that was failing, saying it could not parse the package.json when it was trying to npm:install some of dependencies (angular, moment etc). We don't get any verbose logging with that. To further complicate things, we are doing all this in Docker off a base Ubuntu 14.04.2 image. We are using an older version of JSPM, so maybe we need to upgrade that as well. |
|
I'm using a version newer than 1.3 and getting this error: |
|
@cah-oster Until we have this change rolled back, you'll need to update to a newer version of |
|
@othiym23 that fixed it. thanks. I read in another issue that was closed as a duplicate of this, that npm version > 1.3 was good enough. |
|
@cah-oster Your comment caused me to dig more deeply into the source, so I was able to figure out roughly when the change had been made. Thanks! |
othiym23
changed the title
|
Retitled issue to reflect the underlying issue. |
|
Is there an ETA to solving this issue? |
|
@mikedoug I believe that it should be resolved now, in that the responses returned to the npm CLI are now only gzipped if the client sends an |
|
It is not working here: npm http GET https://registry.npmjs.org/gulp |
|
We worked around it by upgrading our Node to 4.x from nodesource.com's debian packages. This includes 2.15.0 which upgrades nicely to 2.15.2 and does not suffer from these problems. |
|
Still getting the same errors |
|
this is my oversight i need smarter invalidation. The older npm clients pull specific verisons by url directly whereas the suported clients pull the top level document. I apologize again for the delay in resolving this and now that we've found another case ill update again soon. |
|
@mrjefftang how do things look for you now? The per version invalidation is still in progress but i verified the urls in your issue comment have been purged. |
|
|
thanks @terenya-aleksandr ill look at these! note that if you don't run |
|
Thanks @soldair that fixed it for all of my package dependencies. |
|
@terenya-aleksandr concat-map/0.0.1 was not in my invalidation list yet. i ran just that one and /balanced-match for good measure. its really hard to tell whats going on because logging was so racy in those versions. helps? |
|
just so anyone still effected knows my strategy. Hopefully this will ensure we don't miss anything folks are actually using. These old urls had support for dynamic version ranges and things that makes it impossible to generate the url strings any other way. Please post module version urls you are still having issues with and ill look into each to make sure we have everything sorted out. Don't forget to update: |
|
did |
|
@chiefy i need a bit more log data to see the url that had the encoding issue. the logging is very racey Anyone still experiencing the issue can feel free to contact us through support@npmjs.com so we can track these as regular tickets. I dont want to miss anyone. |
|
|
@terenya-aleksandr could we move this to ticket via an email to support@npmjs.com so i can help you more directly? and or I need a gist to your npm-debug.log |
|
|
@terenya-aleksandr i cleared open/0.0.5 and tiny-lr-fork/0.0.5. lets continue in a support ticket if you are still having issues so we can use this more for status announcements. support@npmjs.com |
|
@soldair thanks. Ok, let's continue in a support ticket. |
|
ok folks. We setup a process that will catch anything that you might have an issue with that we haven't been able to purge manually. this change resolves this issue. If you get an encoding error please npm cache clear. wait 20 or so seconds and try again. |
|
we had a some valid package names that were incorrectly filtered by a regular expression. this should be resolved now for you folks using socket.io-client etc =) |
|
Still seeing errors while using Kappa to proxy the npm registry. There is an update that can handle the gzipped packages that works fine, but with an old install it still doesn't seem to be working any better yet. Unfortunately, there isn't any npm-debug.log since it is a proxy client, but I am noticing that every package with the version in the url (eg. /angular-messages/-/angular-messages-1.4.8.tgz) is fine, while those directly querying (eg. /angular-annotorious) are having failures. Is this because you are checking the client string? The proxy server will pass along the client npm version in the request, which could be high enough to handle gzipped content (eg v3.8.3) but the proxy itself doesn't necessarily know to expect gzipped content. I assume given this that older Kappa versions will be permanently broken, for anyone else with similar problems. |
|
What was not working for me now is, I think you may have cracked it :) |
|
Same here. Thanks a lot guys :) |
|
@sarsenault we are not checking agent strings. if the proxy passes tarballs are always gzip and the npm client itself unpacks them. There was no change there so it makes sense that this would work. |
|
fwiw, npm did a post-mortem on this subject. thank you @othiym23 @soldair ! |
and others
The text was updated successfully, but these errors were encountered: