မျှဝေသော proxy cache အတွက် Vary: * ဆိုသည်မှာ အဘယ်နည်း

Vary: * ပါသော သိမ်းထားသည့် တုံ့ပြန်မှုသည် ပုံမှန် Vary ကိုက်ညီမှု စမ်းသပ်မှုတွင် အမြဲ ကျရှုံးသည်။ URL နှင့် မြင်နိုင်သော ခေါင်းစီးများ ဆင်တူသည်ဟူသော အကြောင်းကြောင့်သာ နောက်ပိုင်း တောင်းဆိုမှုသည် တူညီသော ကိုယ်စားပြုမှုကို ရပိုင်ခွင့်ရှိသည်ဟု proxy က ကောက်ချက်ချနိုင်မည် မဟုတ်ပါ။

၎င်းကို အောက်ပါနှင့် နှိုင်းယှဉ်ပါ:

Vary: Accept-Encoding

ယင်းသည် cache နှိုင်းယှဉ်နိုင်သော တောင်းဆိုမှု အကွက်ကို အမည်ပေးသည်။ ကတ်စုံသင်္ကေတက ဤကဲ့သို့ ခေါင်းစီး နှိုင်းယှဉ်မှုသည် မလုံလောက်ကြောင်း ဆိုသည်။ လတ်ဆတ်မှု သို့မဟုတ် cache အရွယ်အစား တိုးခြင်းသည် လိုအပ်နေသော ရွေးချယ်မှု အချက်အလက်ကို မပေးပါ။

ကွာခြားချက်မှာ သိမ်းဆည်းမှုနှင့် ပြန်လည်အသုံးချမှုကြားတွင် ရှိသည်။ cache သည် အတည်ပြုမှုအတွက် အသုံးဝင်သော အချက်အလက်ကို သိမ်းထားနိုင်သော်လည်း သိမ်းထားသော ကတ်စုံ မူကွဲသည် နောက်တောင်းဆိုမှုကို ဖြည့်ဆည်းပေးနိုင်သည့် ပုံမှန် ကိုက်ညီသော တုံ့ပြန်မှု မဖြစ်လာပါ။ proxy သည် များသောအားဖြင့် မူလအရင်းအမြစ်ကို ဆက်သွယ်ရန် လိုအပ်သည်။

တုံ့ပြန်မှု မူဝါဒက အပလီကေးရှင်းကို ဖော်ပြပါစေ

သင်သည် မူလအရင်းအမြစ်ကို ထိန်းချုပ်ပြီး ကိုယ်စားပြုမှုသည် အမှန်တကယ် ဖော်ထုတ်နိုင်သော တောင်းဆိုမှု ခေါင်းစီးများဖြင့်သာ ကွဲပြားပါက ထိုအကွက်များကို တိကျစွာ အမည်ပေးပါ။ ထိုဥပမာ cache လုပ်နိုင်သည်ဟူသော အကြောင်းကြောင့်သာ ကတ်စုံသင်္ကေတကို Accept-Encoding ဖြင့် အစားမထိုးပါနှင့်: အပလီကေးရှင်းသည် ဘာသာစကား၊ ခွင့်ပြုချက် သို့မဟုတ် ထိုခေါင်းစီးများ ပြင်ပ အချက်အလက်များဖြင့်လည်း ကွဲပြားနိုင်သည်။

အကြောင်းအရာသည် ကိုယ်ပိုင်ဖြစ်ပါက သို့မဟုတ် မသိမ်းသင့်ပါက သက်ဆိုင်ရာ cache မူဝါဒဖြင့် ဖော်ပြပါ။ Vary ကို ဖယ်ရှားခြင်းသည် ကိုယ်ပိုင်စိတ်ကြိုက် အကြောင်းအရာကို မျှဝေရန် လုံခြုံစေမည် မဟုတ်ပါ။

Squid ၏ vary_ignore_expire ဆက်တင်သည် ကွဲပြားသော တုံ့ပြန်မှုများအတွက် သက်တမ်းကုန်ဆုံးမှု ကိုင်တွယ်ခြင်းနှင့် သမိုင်းဝင် HTTP အပြုအမူနှင့် သက်ဆိုင်သည်။ ၎င်းသည် ကတ်စုံသင်္ကေတကို ကိုက်ညီစေသော ခလုတ် မဟုတ်ပါ။