Vary: * ધરાવતો સંગ્રહિત પ્રતિભાવ હંમેશા સામાન્ય Vary મેળ પરીક્ષણમાં નિષ્ફળ જાય છે. પ્રોક્સી એવું તારણ કાઢી શકતું નથી કે પછીની વિનંતી સમાન રજૂઆત માટે હકદાર છે, ફક્ત તેનું URL અને દેખાતા હેડર સમાન દેખાય છે એટલા માટે.

આની સાથે સરખામણી કરો:

Vary: Accept-Encoding

આ એક વિનંતી ક્ષેત્રનું નામ આપે છે જે કેશ સરખાવી શકે છે. વાઇલ્ડકાર્ડ કહે છે કે આ પ્રકારની હેડર સરખામણી પૂરતી નથી. તાજગી કે કેશનું કદ વધારવાથી ખૂટતી પસંદગીની માહિતી મળતી નથી.

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

પ્રતિભાવ નીતિને એપ્લિકેશનનું વર્ણન કરવા દો

જો તમે મૂળ નિયંત્રિત કરો છો અને રજૂઆત ખરેખર ફક્ત ઓળખી શકાય તેવા વિનંતી હેડર પ્રમાણે બદલાય છે, તો તે ક્ષેત્રોને સચોટ રીતે નામ આપો. ફક્ત એ ઉદાહરણ કેશયોગ્ય છે એટલા માટે વાઇલ્ડકાર્ડને Accept-Encoding થી બદલો નહીં: એપ્લિકેશન ભાષા, અધિકૃતિ કે તે હેડરની બહારની માહિતી પ્રમાણે પણ બદલાઈ શકે છે.

જો સામગ્રી ખાનગી છે અથવા સંગ્રહિત ન થવી જોઈએ, તો તેને અનુરૂપ કેશ નીતિ દ્વારા વ્યક્ત કરો. Vary દૂર કરવાથી વ્યક્તિગત સામગ્રી શેર કરવા માટે સુરક્ષિત બનતી નથી.

Squid નું vary_ignore_expire બદલાતા પ્રતિભાવો માટે સમાપ્તિ સંચાલન અને ઐતિહાસિક HTTP વર્તન સાથે સંબંધિત છે. તે વાઇલ્ડકાર્ડને મેળ ખાવા માટે મજબૂર કરતો સ્વિચ નથી.

સંબંધિત લેખો