SOCKS-prokuriloj en .NET HttpClient: subtenataj URI-skemoj
Uzu la dokumentitajn SOCKS-prokurilajn URI-skemojn de kongrua .NET HTTP-traktilo anstataŭ supozi, ke malnovaj triapartaj receptoj ankoraŭ necesas.
Malnovaj respondoj rekomendas plian SOCKS-traktilon ĉar ili celas pli malnovan .NET-retstakon. Moderna subtenata .NET HTTP-stako povas uzi dokumentitajn SOCKS-prokurilajn URI-skemojn.
var handler = new HttpClientHandler
{
Proxy = new WebProxy("socks5://203.0.113.10:1080"),
UseProxy = true
};
using var client = new HttpClient(handler);La finpunkto estas nur ilustra. La listo de SOCKS5-prokuriloj proponas publikajn kandidatojn por ĉi tiu socks5 WebProxy-URI; uzu la version subtenatan de la efektiva traktilo. Kontrolu la celan kadron, la rulmedian, la platformon kaj la efektivan traktilon uzatan de la aplikaĵo antaŭ ol apliki ĉi tiun ekzemplon al pli malnova .NET Framework-procezo.
La nuna prokurila dokumentaro de Microsoft listigas socks4, socks4a kaj socks5. Tiuj nomoj priskribas protokolan konduton. Nur porthumero ne elektas la SOCKS-version, kaj la skribmaniero socks5h de curl ne estas universala URI-skemo akceptata de ĉiu kliento.
Por aŭtentigita SOCKS5-servo, agordu la legitimilojn laŭ la interfaco subtenata de la traktilo. SOCKS4 kaj SOCKS4a ne provizas la saman pasvortan aŭtentigan mekanismon.
La celURL restas senŝanĝa. HTTPS-peto ankoraŭ starigas kaj kontrolas la TLS de la celo tra la prokurila vojo; aldoni SOCKS ne estas kialo malŝalti tiun kontrolon.