Need a way to specify a different proxy for imports and requests

[mem]

Feature Description

imports (e.g. import jsonpath from "https://jslib.k6.io/jsonpath/1.0.2/index.js") use the same global proxy configuration as requests (e.g. http.request("GET", "https://grafana.com/"). This prevents setting different policies between what the imports can access and what the requests can access. One might want to restrict imports to certain domains (e.g. k6.io) or one might want to introduce caching for the imports but not for the requests.

Suggested Solution (optional)

Add new environment variables, e.g. K6_HTTP_PROXY, K6_HTTPS_PROXY and K6_NO_PROXY, to specify a proxy to be used for imports and fall back to the non-K6_ versions if they are not set. Setting these to an empty value would mean no proxy. This makes the set up backwards compatible (if someone is running k6 with the variables set, they get the same behavior the are getting today).

This can be implemented by modifying the client and the transport that is used to load imports.

Already existing or connected issues / PRs (optional)

This is tangentially related to #1045

[codebien]

Hey @mem,
thanks for your feature request.

One might want to restrict imports to certain domains (e.g. k6.io) or one might want to introduce caching for the imports but not for the requests.

Let me understand this point better. Do you have a real case where you want at the same time a proxy for the k6 internal operations (like modules loading) and another for the script's defined requests (or even more policies) where having HTTP(s)_PROXY + NO_PROXY doesn't solve the problem, right?

The proposed solution would work but has the same con reported in #1045 of creating one more global option for a specific case.

This is mainly the reason why we are highly prioritizing a new configurable HTTP client. Having the ability to specify a proxy for the used HTTP client should enable the case where the HTTP(s)_PROXY variables are used as the global configuration and a specific proxy is assigned for every client/request. In this way, the k6 internal requests can use the global option and the script's defined requests the related assigned policy.

Just to make clear, the proxy configuration is not expected to land in the first iteration. Hopefully, it will be part of stage 2/3 (eventually, with an external contribution, we could speed up the dev phase of the proxy part).