HTTP/2 funkcias ene de la SOCKS-tunelo de Go

Klonu la norman HTTP-transportilon, elektu la SOCKS-prokurilon kaj inspektu la celprotokolon efektive intertraktitan.

SOCKS-tunelo portas TCP-konekton. Go povas fari TLS kun la celo tra tiu tunelo kaj intertrakti HTTP/2 tie; la SOCKS-servilo mem ne bezonas paroli HTTP/2.

En programo, kiu konservas la norman defaŭltan transportilon de Go, klonu ĝian agordon kaj elektu la prokurilon:

import (
    "net/http"
    "net/url"
    "time"
)

proxyURL := &url.URL{
    Scheme: "socks5",
    Host: "proxy.example:1080",
}
transport := http.DefaultTransport.(*http.Transport).Clone()
transport.Proxy = http.ProxyURL(proxyURL)
client := &http.Client{
    Transport: transport,
    Timeout: 30 * time.Second,
}

La prokurilo kaj la celo restas malsamaj valoroj. Elektu SOCKS5-finpunkton el la listo de SOCKS5-prokuriloj por la prokurila valoro; HTTP/2 ankoraŭ estas intertraktata kun la celo. Uzu client por peti la realan HTTPS-servan URL-on, poste fermu la respondkorpon per la normala vivciklo de la programo.

La norma defaŭlta transportilo subtenas HTTP/2. Klonado konservas tiun agordon dum ĝi permesas ŝanĝi la prokurilan elekton. La tipsupozo supozas, ke la programo ne anstataŭigis http.DefaultTransport per alia RoundTripper.

Por aparte konstruita transportilo, revizuu ĝian HTTP/2-agordon, precipe kiam vi provizas proprajn dial- aŭ TLS-hokojn. Go elmetas ForceAttemptHTTP2 kaj, en pli novaj eldonoj, eksplicitan Protocols-agordon por tiuj elektoj.

La celo ankoraŭ devas proponi HTTP/2 per TLS-intertraktado. Inspektu la valoron Proto aŭ ProtoMajor de la sukcesa respondo por vidi, kio estis uzita. Sukcesa HTTPS-peto tra SOCKS mem ne pruvas, ke la intertraktita protokolo estis HTTP/2.

Rilataj artikoloj