HTTP/2 får plass inne i SOCKS-tunnelen til Go
Klon standard-HTTP-transporten, vel SOCKS-proxyen og undersøk destinasjonsprotokollen som faktisk vart forhandla.
Ein SOCKS-tunnel ber ei TCP-tilkopling. Go kan utføre TLS med destinasjonen gjennom den tunnelen og forhandle HTTP/2 der; SOCKS-tenaren treng ikkje sjølv å snakke HTTP/2.
I eit program som held på standardtransporten til Go, klon konfigurasjonen og vel proxyen:
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,
}
Proxyen og destinasjonen er framleis ulike verdiar. Vel eit SOCKS5-endepunkt frå SOCKS5-proxylista for proxyverdien; HTTP/2 vert framleis forhandla med destinasjonen. Bruk client til å be om den verkelege HTTPS-teneste-URL-en, og lukk deretter svarteksten gjennom den normale livssyklusen til applikasjonen.
Standardtransporten støttar HTTP/2. Kloning held på denne konfigurasjonen og lèt proxyvalet endre seg. Typesjekken føreset at programmet ikkje har bytt ut http.DefaultTransport med ein annan RoundTripper.
For ein separat bygd transport, gå gjennom HTTP/2-konfigurasjonen, særleg når du oppgir eigendefinerte dial- eller TLS-krokar. Go eksponerer ForceAttemptHTTP2 og, i nyare utgåver, eksplisitt Protocols-konfigurasjon for desse vala.
Destinasjonen må framleis tilby HTTP/2 gjennom TLS-forhandling. Undersøk Proto- eller ProtoMajor-verdien til det vellukka svaret for å sjå kva som vart brukt. Ein HTTPS-førespurnad som lukkast gjennom SOCKS bevisar ikkje i seg sjølv at den forhandla protokollen var HTTP/2.