You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm currently hosting several versions of this library on some AWS instances. I've been having people reporting issues with package installation timeouts, which seem to be stemming from the following line of code:
All packages are having their baseUrl set to whatever the server's config.host property was set. In theory, this should work with no issues. In practice, however, it is relatively common to have the server's bound hostname different from the hostname client's are using for requests (think of load-balanced servers, for example).
What I think would correct this issue would be swapping over to using the requested hostname in the http request, rather than the config.host value.
Here's a screencap of the issue clients are running into when trying to use our private npm repo:
The text was updated successfully, but these errors were encountered:
Interesting, multiple host names was not something I had considered. Unfortunately, getting the actual host an http request was made against is non-trivial. Http 1.1 added the host header, which could be used, but I'm not sure how various proxies and load balancers handle that header.
Are your deployed instances being accessed from multiple host names? If not, setting config.host to use the host used by clients should work.
I think providing a config option to use req.headers.host would be reasonable, and ideally falling back to the current method if the request does not have a host header. I'll have to look a bit more into this to know if there is another solution, or if there are additional things that can be done to make more complicated setups work.
I created a pr #88 to add a config option to do auto detecting of hosts. I don't think it will work perfectly in all scenarios, but if you would not mind testing it, and seeing if it works for you I can finish up the PR and get it merged. Didn't want to spend too much more time on it if it does not work for your use case.
I'm currently hosting several versions of this library on some AWS instances. I've been having people reporting issues with package installation timeouts, which seem to be stemming from the following line of code:
All packages are having their baseUrl set to whatever the server's
config.host
property was set. In theory, this should work with no issues. In practice, however, it is relatively common to have the server's bound hostname different from the hostname client's are using for requests (think of load-balanced servers, for example).What I think would correct this issue would be swapping over to using the requested hostname in the
http
request, rather than theconfig.host
value.Here's a screencap of the issue clients are running into when trying to use our private
npm
repo:The text was updated successfully, but these errors were encountered: