Proposal: HTTP proxy support #309
Replies: 4 comments 16 replies
-
Any feedback from the team before I start implementing this feature? |
Beta Was this translation helpful? Give feedback.
-
Sorry for the late response! Some general thoughts: Something that we're lacking currently is the ability to use OSS packages through an internal mirror. This is a feature that we would like to land in our next release (0.26). I'm thinking that what we want here is actually a rewrite rule. As a practical example: it would be good for Also: I think we want the rewrite to be configurable on a machine level, via the settings file. Would also be good if this is configurable on a per-evaluator basis, and as well as a CLI flag, and via the settings in Sidenote: It might be good to discuss this in a more high throughput setting. A bunch of us hang out in the pkl-community discord channel. |
Beta Was this translation helpful? Give feedback.
-
Gradle uses the JVM proxy settings, so it should be good enough for Pkl to default to those. (I don't actually know if that's currently the case.) JVM proxy settings should also be good enough for Setting a proxy via |
Beta Was this translation helpful? Give feedback.
-
I think it's best if you take over from here. |
Beta Was this translation helpful? Give feedback.
-
@stackoverflow suggested to have a discussion before I start working on this feature. Here is my proposal:
Features:
similar to cURL's
--noproxy
and Java's-Dhttp.nonProxyHosts
.http_proxy
,HTTPS_PROXY
,ALL_PROXY
andNO_PROXY
environment variables.https://everything.curl.dev/usingcurl/proxies/env
Java does not honor these environment variables:
https://bugs.openjdk.org/browse/JDK-8292530
API:
--proxy [http://]host[:port]
https://curl.se/docs/manpage.html#-x
--noproxy <no-proxy-list>
https://curl.se/docs/manpage.html#--noproxy
CliBaseOptions
HttpClient.Builder
org.pkl.executor.Executor
(seems fairly pointless)Testing:
https://wiremock.org/docs/junit-jupiter/
https://www.mock-server.com/mock_server/running_mock_server.html#junit_test_extension
Open questions:
The only authentication method that is directly supported by
java.net.http.HttpClient
is basic authentication.Basic proxy authentication is disabled by default (apparently because of the security risk) and can only be enabled via a system property.
--noproxy
.cURL and Java support a slightly different syntax.
--noproxy
.Java: "The default value excludes all common variations of the loopback address."
cURL: None.
Non-goals:
java.net.http.HttpClient
does not support SOCKS proxies.Setting
java.net.Proxy.Type.SOCKS
has no effect.https://bugs.openjdk.org/browse/JDK-8214516
java.net.http.HttpClient
does not support HTTPS proxies.https://dev.to/kdrakon/httpclient-can-t-connect-to-a-tls-proxy-118a
Usually, SSL tunneling through an HTTP proxy should be good enough.
However, basic authentication with an HTTP proxy leaks credentials.
Java supports this feature (only) by using
java.net.ProxySelector.getDefault()
and setting system property
java.net.useSystemProxies=true
. The default isfalse
.Neither cURL nor GraalVM native image supports this feature.
Using java.net.useSystemProxies has no effect oracle/graal#4285
PklProject
,~/.pkl/someFile
).Beta Was this translation helpful? Give feedback.
All reactions