Python Requests-omdirigeringer: None kontra tomme proxyverdier
Hold intensjonen om direkte ruting eksplisitt gjennom omdirigeringer i stedet for å stole på en None-verdi som fjerner en mappingoppføring.
Hvis en direkte forespørsel når en omdirigering og den neste utvekslingen mislykkes på en proxy, undersøk overgangen. Requests bygger opp proxyrelaterte innstillinger på nytt for omdirigeringer og kan rådføre seg med miljøet igjen når Sessionen stoler på det.
| Mappingverdi | Hva som skjer under sammenslåingen |
|---|---|
None | Nøkkelen fjernes, og en manglende oppføring blir stående som en senere gjennomgang kan fylle fra miljøet. |
| En tom streng | Den eksplisitte verdien blir stående; den kan bevare intensjonen om direkte ruting for det skjemaet. |
For en eksisterende Session, oppgi destinasjonsskjemaene som er involvert i den direkte operasjonen:
response = session.get(
'https://example.com/start',
proxies={'http': '', 'https': ''},
timeout=15,
)Sjekk eventuelle ekstra vertsspesifikke mappinger og egendefinerte adaptere hvis applikasjonen tilbyr dem. Denne rutinginndataen overstyrer ikke enhver mulig policy som disse komponentene implementerer.
Behold hver URL i diagnostikken
Registrer den opprinnelige URL-en, hver omdirigeringsplassering, svarstatusen og trinnet som mislykkes. Overgangen fra HTTP til HTTPS endrer den relevante skjemanøkkelen; en ny vert kan falle utenfor den første vertens omgåelsesregel. En rapport som bare inneholder den opprinnelige URL-en skjuler begge overgangene.
Å observere ett svar med omdirigeringsfølging deaktivert kan avdekke grensen. Undersøk plasseringen som data før du bestemmer deg for å be om den; ikke send de opprinnelige legitimasjonene vilkårlig til en ny destinasjon.
En egen Session med miljøoppdagelse deaktivert er et annet alternativ når applikasjonen bevisst eier alle ruting- og tillitsinndata. Det påvirker også automatisk oppdagelse av legitimasjon og CA, så velg det som en applikasjonspolicy snarere enn en rutinemessig omdirigeringsreparasjon.