Proxy-IP og port: Hvilket format trenger appen din?

Noen apper vil ha IP:port. Andre trenger en URL som begynner med http:// eller socks5://. Nettleserinnstillinger har ofte separate felt for adresse og port. Samme endepunkt kan derfor vises i flere formater uten at adressen endres.

En IPv4-oppføring

Anta at en HTTP-proxyliste gir deg eksempelproxyen 203.0.113.10:8080 for HTTP.

Ikke oppgi porten to ganger. Hvis appen allerede har et portfelt, kan 203.0.113.10:8080 i vertsfeltet få den til å forsøke å slå opp hele strengen som et vertsnavn. Legg heller ikke til et skjema i et felt som uttrykkelig forventer bare en IP-adresse.

Skjemaet må passe til tjenesten. Velg HTTP eller SOCKS5 etter klientstøtten før du konverterer adressen. Å skrive socks5:// foran et HTTP-endepunkt endrer det klienten sender; det aktiverer ikke SOCKS5 på serveren.

IPv6 trenger hakeparenteser i en URL

En IPv6-adresse inneholder allerede kolon, så URL-en omslutter adressen med hakeparenteser før porten legges til:

http://[2001:db8::10]:8080
socks5://[2001:db8::10]:1080

Uten parentesene er grensen mellom adresse og port tvetydig. En app med separate felt vil vanligvis ha 2001:db8::10 som vert og 8080 som port; følg appens inndataformat. Begge adressene her er dokumentasjonseksempler, ikke aktive proxyer.

Parse URL-er i stedet for å dele ved hvert kolon

Et lite Python-skript kan håndtere IPv4-URL-er og IPv6-URL-er med parenteser med standardparseren for URL-er:

from urllib.parse import urlsplit

proxy = urlsplit("http://[2001:db8::10]:8080")
print(proxy.scheme)
print(proxy.hostname)
print(proxy.port)

Egenskapen hostname returnerer adressen uten parentesene. Å dele den opprinnelige strengen ved hvert kolon ville ødelegge dette eksempelet. I en faktisk importfunksjon bør du også avvise manglende verter, skjemaer som ikke støttes og porter utenfor 1–65535. Parsing av en URL gir delene dens; det beviser ikke at tjenesten finnes.

Når listen inneholder brukernavn og passord

Et vanlig URL-format er http://username:password@host:port. Tegn som @, # og / i påloggingsopplysninger krever riktig URL-koding. Har klienten egne felt for påloggingsopplysninger, er disse vanligvis enklere enn å sette sammen URL-en manuelt.

Kontroller leverandørens opprinnelige format før du konverterer en kolonseparert streng med påloggingsopplysninger. Fire kolonseparerte felt har ingen universell betydning, og passordet kan selv inneholde kolon. En parser for enkle IP:port-linjer bør ikke gjette seg stille gjennom et annet format.