Respondo ricevita tra proksejo povas redoni relativan Location:

Location: ../new/

Moderna HTTP permesas URI-referencon ĉi tie. Solvu ĝin rilate al la URL, kiu produktis la respondon. Se tiu URL estis https://docs.example/catalog/old/, la supra referenco identigas https://docs.example/catalog/new/. La gastigantnomo de la proksejo ne estas la bazo.

Por ordinaraj Python urllib-petoj uzu ĝian redirektan traktilon anstataŭ kunigi ĉenojn ĉirkaŭ la prokseja finpunkto:

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()

Por ĉi tiu peto pri publika dokumento sen prokseja aŭtentigo, HTTP-kandidato el la HTTP-prokseja listo povas anstataŭigi la ekzemplan finpunkton, kiam la vojo estas permesata. La klasoj venas el urllib.request. Ĝia normala traktilo sekvas subtenatajn redirektojn ene de siaj limoj. final_url priskribas la finan URL de la rimedo, ne la peranton uzitan por atingi ĝin.

Unue solvu, poste elektu la sekvan vojon

Redirekto povas ŝanĝi la celan gastiganton aŭ skemon. Tial prokseja politiko bazita sur celo devas ankaŭ taksi tiun novan URL. Vojo, kiu funkciis por la unua gastiganto, eble ne estas la vojo por la sekva.

Kiam vi mem efektivigas redirektan traktadon, uzu URI-referencan solvon kun traktado de punktaj segmentoj. Konservu la metodajn regulojn de la reala statuskodo kaj starigu redirektan limon. Aldoni Location al gastigantnomo ne anstataŭas tiun solvan algoritmon.

Se redirekto malsukcesas, konservu la petitan URL, la respondan statuson, la valoron Location kaj la solvitan sekvan URL. Tiuj kvar valoroj kutime montras, ĉu la fiasko apartenas al URL-konstruado aŭ al la konekto provita poste.

Rilataj artikoloj