'n Jenkins-inprop wat 'n uitgaande HTTP-versoek doen, kan Jenkins se openbare proxybewuste kliënthulpmiddel gebruik:

HttpClient client = ProxyConfiguration.newHttpClient();
HttpRequest request = ProxyConfiguration.newHttpRequestBuilder(
        URI.create("https://service.example/status"))
    .GET()
    .build();
HttpResponse<Void> response = client.send(
    request, HttpResponse.BodyHandlers.discarding());

Die fragment gebruik hudson.ProxyConfiguration-, java.net.URI- en java.net.http-tipes. Die oproeper hanteer I/O en onderbreking deur sy normale inpropvloei. Die liggaamsverwerker verbruik en verwerp die reaksieliggaam.

newHttpClient en sy bouerkoppelvlak is beskikbaar sedert Jenkins 2.379. In 'n kontroleerder-JVM pas hulle Jenkins se ondersteunde proxykonfigurasie toe. Hergebruik die kliënt eerder as om een vir elke versoek te skep.

Dit voorkom dat die kontroleerder se gestoorde proxynaam en -wagwoord in 'n afsonderlik opgestelde vervoer gekopieer word. 'n Java HTTP-kliënt wat afsonderlik geskep is, word nie proxybewus net omdat die kontroleerder-koppelvlak 'n proxy-inskrywing het nie.

Vir versoeke wat 'n Authorization-opskrif vir die bestemming verskaf, hersien die gedokumenteerde beperking vir geauthentiseerde proxy's op Java 17 en later. Die Javadoc wys spesifiek op dié kombinasie; die keuse van hierdie hulpmiddel verwyder nie daardie kliëntbeperking nie.

Verwante artikels