Cache-Control: no-cache સાથે પ્રોક્સી દ્વારા થતા ડાઉનલોડની ફરી માન્યતા ચકાસો

ડાઉનલોડ URL બદલ્યા વિના માન્ય કરેલો પ્રતિભાવ માંગો અને ફરી ચકાસણીને સંગ્રહ પરના પ્રતિબંધ સાથે ગૂંચવશો નહીં.

ડાઉનલોડ URL સાચું છે, પરંતુ શેર કરેલી પ્રોક્સી પાસે હજી સંગ્રહિત પ્રતિભાવ છે. જો ક્રિયાને મૂળ સાથે માન્ય કરેલો પ્રતિભાવ જોઈએ, તો એ શરત વિનંતી પર મૂકો:

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)

આ ટુકડો ધારે છે કે એપ્લિકેશન પાસે બાઇનરી આઉટપુટ સ્ટ્રીમ છે અને તે HTTPS download_url પૂરું પાડે છે. પ્રોક્સી પ્રમાણીકરણ વિના મંજૂર જાહેર ડાઉનલોડ અજમાવવા માટે, openerમાં HTTP પ્રોક્સી યાદીમાંથી HTTP એન્ડપોઇન્ટ ઉમેદવાર વાપરો; વિનંતીની કેશ શરત એ જ રહે છે. તે મૂળ સ્રોત URL રાખે છે અને વિનંતી માર્ગ પરની કેશને ફરી ઉપયોગ પહેલાં માન્યતા ચકાસવા કહે છે.

માન્યતા ચકાસણી સંગ્રહિત બાઇટ્સનો ફરી ઉપયોગ કરી શકે છે

no-cache મેળવતી અનુરૂપ કેશ મૂળ સાથે સફળ માન્યતા ચકાસણી વિના સંગ્રહિત પ્રતિભાવમાંથી આ વિનંતી પૂરી કરી શકતી નથી. મૂળ પુષ્ટિ કરી શકે છે કે સંગ્રહિત રજૂઆત હજી માન્ય છે, તેથી ક્રિયાને મૂળમાંથી અપરિવર્તિત ફાઇલ ફરી મોકલવાની જરૂર નથી.

વિનંતીનું max-age=0 વય મર્યાદા વ્યક્ત કરે છે. જ્યારે એપ્લિકેશન એ મર્યાદાથી જૂનો ન હોય એવો પ્રતિભાવ માંગે ત્યારે તે ઉપયોગી છે, પરંતુ તે સંગ્રહ પર પ્રતિબંધ નથી. હમણાં જ બનાવેલો પ્રતિભાવ તેને પૂરો કરી શકે છે.

એક રેન્ડમ ક્વેરી પેરામીટર ઉમેરવાથી બીજું લક્ષ્ય URI માંગાય છે. તે બીજી કેશ એન્ટ્રી બનાવી શકે છે અથવા એપ્લિકેશનનો પ્રતિભાવ પણ બદલી શકે છે. ક્વેરી પેરામીટર ત્યારે જ વાપરો જ્યારે તે સ્રોતના ઇચ્છિત ઇન્ટરફેસનો ભાગ હોય.

સામાન્ય HTTPS CONNECT માટે, ટનલિંગ પ્રોક્સી TLSની અંદર આ હેડર જોઈ શકતી નથી. નીતિ તો પણ મૂળ અને ડિક્રિપ્ટ થયેલી HTTP આપલે સંભાળતી કેશ સુધી પહોંચી શકે છે. સંગ્રહિત પ્રતિભાવને ટનલને આભારી ગણતા પહેલાં તે ખરેખર ક્યાં રહે છે તે તપાસો.

સંબંધિત લેખો