Eit svar motteke gjennom ein proxy kan returnere ein relativ Location:

Location: ../new/

Moderne HTTP tillèt ei URI-referanse her. Løys ho opp mot URL-en som laga svaret. Viss den URL-en var https://docs.example/catalog/old/, peikar referansen ovanfor på https://docs.example/catalog/new/. Vertsnamnet til proxyen er ikkje basen.

For vanlege Python urllib-førespurnader nyttar du omdirigeringshandsamaren i staden for å setje saman strengar rundt proxy-endepunktet:

opener = build_opener(ProxyHandler({
    "https": "http://proxy.example:8080",
}))
with opener.open("https://docs.example/catalog/old/",
                 timeout=15) as response:
    final_url = response.geturl()

For denne førespurnaden om eit offentleg dokument utan proxy-autentisering kan ein HTTP-kandidat frå HTTP-proxylista erstatte døme-endepunktet når ruta er tillaten. Klassane kjem frå urllib.request. Den vanlege handsamaren følgjer støtta omdirigeringar innanfor sine grenser. final_url skildrar den endelege URL-en til ressursen, ikkje mellomleddet som vart brukt for å nå han.

Løys opp først, vel deretter neste rute

Ei omdirigering kan endre målverten eller skjemaet. Ei destinasjonsbasert proxy-policy må difor òg vurdere den nye URL-en. Ei rute som fungerte for den første verten, er kanskje ikkje ruta for den neste.

Når du sjølv implementerer handsaming av omdirigeringar, bruk URI-referanseoppløysing med handsaming av punktsegment. Hald på metode-reglane for den faktiske statuskoden, og set ei omdirigeringsgrense. Å leggje Location til eit vertsnamn er ikkje ei erstatning for den oppløysingsalgoritmen.

Viss ei omdirigering mislukkast, behald den førespurde URL-en, svarstatusen, Location-verdien og den oppløyste neste URL-en. Desse fire verdiane viser vanlegvis om feilen høyrer til URL-konstruksjonen eller til tilkoplinga som vart freista etterpå.

Relaterte artiklar