URL ya upakuaji ni sahihi, lakini proksi inayoshirikiwa bado ina jibu lililohifadhiwa. Ikiwa operesheni inahitaji jibu lililothibitishwa na chanzo, weka hitaji hilo kwenye ombi:

from urllib.request import ProxyHandler, Request, build_opener
import shutil

opener = build_opener(ProxyHandler({
    "https": "http://proxy.example:8080",
}))
request = Request(download_url, headers={"Cache-Control": "no-cache"})
with opener.open(request, timeout=15) as response:
    shutil.copyfileobj(response, output)

Kipande hiki kinadhania kuwa programu inamiliki mtiririko wa pato wa jozi na hutoa HTTPS download_url. Ili kujaribu upakuaji wa umma ulioruhusiwa bila uthibitishaji wa proksi, tumia mwombaji wa kituo cha mwisho cha HTTP kutoka orodha ya proksi za HTTP kwenye kifunguzi; hitaji la akiba la ombi linabaki lilelile. Huhifadhi URL asilia ya rasilimali huku likiomba akiba zilizo kwenye njia ya ombi zithibitishe kabla ya kutumia tena.

Uthibitishaji unaweza kutumia tena baiti zilizohifadhiwa

Akiba inayozingatia kanuni inayopokea no-cache haiwezi kutimiza ombi hili kutoka kwa jibu lililohifadhiwa bila uthibitishaji uliofaulu na chanzo. Chanzo kinaweza kuthibitisha kuwa uwakilishi uliohifadhiwa bado ni halali, kwa hivyo operesheni haitaji kusambaza tena faili isiyobadilika kutoka chanzo.

max-age=0 kwenye ombi huonyesha kikomo cha umri. Ni muhimu wakati programu inataka jibu lisilozidi umri huo, lakini si marufuku ya kuhifadhi. Jibu lililoundwa hivi punde linaweza kulitimiza.

Kuongeza kigezo cha hoji cha nasibu huomba URI lengwa tofauti. Hilo linaweza kuzalisha ingizo lingine la akiba au hata kubadilisha jibu la programu. Tumia kigezo cha hoji tu wakati ni sehemu ya kiolesura kilichokusudiwa cha rasilimali.

Kwa HTTPS CONNECT ya kawaida, proksi ya handaki haiwezi kuona kichwa hiki ndani ya TLS. Sera bado inaweza kufikia chanzo na akiba zinazoshughulikia mabadilishano ya HTTP yaliyofumbuliwa. Angalia jibu lililohifadhiwa linakoishi kwa kweli kabla ya kulihusisha na handaki.

Makala zinazohusiana