Peti HTTP/3 bezonas UDP-kapablan prokuran vojon
Distingi la QUIC-transporton de HTTP/3 disde ordinaraj HTTP CONNECT-TCP-tuneloj kaj disde la laŭvola UDP-subteno de SOCKS5-servo.
Kliento, kiu sukcese atingas HTTPS per TCP-prokurilo, ne starigis vojon por HTTP/3. HTTP/3 uzas QUIC, kaj QUIC uzas UDP.
Ordinara HTTP CONNECT-tunelo provizas TCP-fluon al sia celo. Ĝi ne fariĝas UDP-ripetilo kiam la URL komenciĝas per HTTPS aŭ kiam la celo aŭskultas je pordo 443.
SOCKS5 ankaŭ bezonas la UDP-vojon
SOCKS5 difinas UDP-asocion, sed kaj la kliento kaj la servilo devas efektivigi ĝin, kaj la ripetila finpunkto devas esti atingebla. Biblioteko, kiu nur proponas SOCKS TCP-teleregilon, ne povas provizi datagraman transporton nur ĉar ĝia tipa nomo diras SOCKS5.
Sammaniere, komponento de ilo nomata proxy povas esti evoluiga simulilo de paketperdo anstataŭ ĝenerala alflu-prokura kliento. Ekzamenu ĝian realan interfacon kaj subtenatan transporton.
Normoj kiel CONNECT-UDP difinas alian manieron transporti UDP tra HTTP-prokura sistemo. Ili postulas subtenon ambaŭflanke kaj ne konfuziĝu kun tradicia CONNECT.
Se la HTTP-kliento retrofalas al HTTP/2 aŭ HTTP/1.1 super TCP, peto povas sukcesi per la ordinara prokurilo dum neniu HTTP/3-konekto estis uzata. Notu la interkonsentitan protokolon kiam tiu distingo gravas.
La utila kompatiga demando do estas specifa: ĉu ĉi tiu kliento povas transporti siajn QUIC-datagramojn tra ĉi tiu prokurilo per ĉi tiu subtenata mekanismo? Funkcianta retumilpaĝo aŭ TCP-porda kontrolo respondas pli malgrandan demandon.