fix: use proxy only for remote requests #4565
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
PR Checklist
Since there are no tests for
http-client
yet, it would be quite a lot of work to add them. Also, the method which was changeduseProxySettings
is private and therefore more difficult to test.What is the current behavior?
With a proxy set according to https://docs.nativescript.org/tooling/docs-cli/general/proxy-set when running unit tests with
tns test android
for example, requests to localhost are being made. Depending on the corporate proxy environment, those requests could be blocked or the proxy can't handle the request, sincelocalhost
is not a remote target. This makes running unit tests with NativeScript impossible in corporate proxy environments, causing exceptions interrupting the test execution. Also, it doesn't make sense to make requests tolocalhost
through a proxy, so this will not have any negative effects.What is the new behavior?
When requests are being made to localhost or 127.0.0.1, even when a proxy is set, the proxy will not be used. Unit tests can be excecuted successfully in an environment with a corporate proxy.
Partially fixes #2313.
A user-defined NO_PROXY is not implemented, but allows for requests to localhost to work properly. Should there be further need to customize which requests should not use the proxy, this could be implemented in a separate PR, but would require discussion on the implementation details.