فرض کریں کہ آپ نے کسی لائبریری کی ویب سائٹ کے مرکزی صفحے پر آج کے اوقاتِ کار بدل دیے ہیں، لیکن کچھ زائرین کو اب بھی پرانے اوقات دکھائی دے رہے ہیں۔ پہلے یہ امکانات الگ کرنے ہوں گے کہ سرور پر اصل مواد تازہ نہیں ہوا، براؤزر نے محفوظ جواب دوبارہ استعمال کیا، یا درمیان کے کسی سرور نے پرانا نسخہ دیا۔ صفحے کو بار بار لوڈ کرنا بذاتِ خود یہ نہیں بتاتا کہ خرابی کس مرحلے میں ہے۔
HTTP کیش موصول شدہ جوابات محفوظ کرتا ہے اور موزوں شرائط پوری ہونے پر انہیں دوبارہ استعمال کرتا ہے۔ اس مضمون میں عام لوگوں کے لیے دستیاب اوقاتِ کار کی فرضی مثال کے ذریعے Cache-Control کی محفوظ کرنے اور توثیق کی ہدایات کو ETag اور 304 کے جوابات سے جوڑا گیا ہے۔ آگے دکھائے گئے تبادلوں کو وضاحت کے لیے مختصر کیا گیا ہے؛ یہ کسی حقیقی لائبریری یا مخصوص سرور پر کی گئی پیمائشیں نہیں ہیں۔ مقصد تمام کیش ختم کرنے کی سفارش نہیں، بلکہ یہ سمجھنا ہے کہ کون سا جواب کب دوبارہ استعمال ہو سکتا ہے۔
1. محفوظ کرنے، جانچ کے بعد استعمال، اور اشتراک کو الگ سمجھیں
کیش کی ہدایات پڑھتے وقت تین الگ سوال رکھیں: کیا جواب محفوظ ہو سکتا ہے، کیا اگلی درخواست پر اسے فوراً دوبارہ استعمال کیا جا سکتا ہے، اور کیا اسے مختلف صارفین کے درمیان بانٹا جا سکتا ہے؟ محفوظ کرنے کی اجازت کا مطلب ہمیشہ بلاجانچ استعمال نہیں، اور تازگی کی جانچ کا مطلب اشتراک کی اجازت نہیں ہے۔ HTTP کیش کے متعلق RFC 9111 ان پہلوؤں میں فرق کرتا ہے۔ یہاں جواب کی ان ہدایات پر بات کی جا رہی ہے جن کے ساتھ فیلڈ کے نام بتانے والے اضافی آرگومنٹس نہیں ہیں۔
| سوال | متعلقہ جوابی ہدایت | ہدایت کا مطلب |
|---|---|---|
| کیا محفوظ کرنا منع ہے؟ | no-store | جواب کو بعد میں دوبارہ استعمال کے لیے محفوظ نہ کرنے کی ہدایت |
| کیا دوبارہ استعمال سے پہلے جانچ ضروری ہے؟ | no-cache | محفوظ کرنے کی اجازت، مگر دوبارہ استعمال سے پہلے کامیاب توثیق لازم |
| کیا مختلف صارفین کے درمیان اشتراک ہو سکتا ہے؟ | private | مشترکہ کیش میں محفوظ کرنا روکتا ہے؛ ذاتی کیش میں ہر قسم کی محفوظ کاری نہیں روکتا |
مثلاً عوامی اوقاتِ کار ایک ہی پتے پر بار بار بدلتے ہوں تو محفوظ نسخہ ہونے کے باوجود دوبارہ استعمال سے پہلے جانچ درکار ہو سکتی ہے۔ اس کے برعکس، ہر صارف کے لیے مخصوص صفحے میں اشتراک کی شرائط بھی اہم ہیں۔ private مشترکہ کیش سے متعلق ہے؛ یہ لاگ اِن یا رسائی کے اختیار کی جانچ کا متبادل نہیں۔ مختلف مقاصد والی ہدایات کو ایک ہی اصول سمجھ لینے سے کارکردگی کے اعداد بہتر ہو سکتے ہیں، لیکن جواب غلط لوگوں کو دکھایا جا سکتا ہے۔
کیش کی پالیسی درج کرتے وقت انتخاب کی وجہ بھی لکھیں۔ کیا عوامی اوقات بدلتے رہتے ہیں؟ کیا لوگو مستقل فائل ہے؟ کیا ایک ہی URL ہر صارف کو مختلف مواد دیتا ہے؟ یہ جوابات کی درجہ بندی کے ابتدائی سوال ہیں، ہر سروس میں نقل کر دینے کے لیے تیار عالمگیر ترتیب نہیں۔ یہ بھی واضح کریں کہ پالیسی براؤزر، CDN یا کس دوسری محفوظ کرنے والی تہہ کے لیے ہے۔
2. no-cache اور no-store صرف نام دیکھ کر منتخب نہ کریں
no-cache نام سے یوں لگ سکتا ہے کہ محفوظ کرنا منع ہے، لیکن اس کا بنیادی اصول دوبارہ استعمال سے پہلے توثیق ہے۔ جواب محفوظ ہو سکتا ہے اور سرور کے یہ تصدیق کرنے پر کہ مواد نہیں بدلا، محفوظ باڈی استعمال کی جا سکتی ہے۔ اس کے مقابلے میں no-store اس جواب کو محفوظ نہ کرنے کی ہدایت دیتا ہے۔ کیا محفوظ کیا جائے اور اگلی درخواست پر کیا جانچا جائے، یہ الگ سوال ہیں؛ اس لیے دونوں ہدایات کا برتاؤ ایک جیسا نہیں۔
fresh کا مفہوم بھی احتیاط سے سمجھیں۔ اس کا مطلب ہے کہ پالیسی جواب کو توثیق کے بغیر دوبارہ استعمال کرنے دیتی ہے، یہ نہیں کہ ویب سائٹ کے منتظم نے اصل مواد ابھی تک نہیں بدلا۔ max-age مقرر ہو تو اصل مواد بدلنے کے بعد بھی کیش اجازت یافتہ مدت ختم ہونے تک پرانا جواب دے سکتا ہے۔ پہلے طے کریں کہ تازہ کاری میں کتنی تاخیر قابلِ قبول ہے؛ بلاوجہ طویل مدت کو ہر قسم کی معلومات کے لیے کارکردگی کا یکساں حل نہ بنائیں۔
MDN کی HTTP کیش کی رہنمائی یہ بھی واضح کرتی ہے کہ نئی no-store ہدایت کو پہلے سے محفوظ نسخہ مٹانے کا حکم نہیں سمجھنا چاہیے۔ ایک ہی URL کے نئے جواب میں no-store لگانے سے سابقہ نسخے کے حذف ہونے کی ضمانت نہیں ملتی۔ اگر پرانا نسخہ ابھی قابلِ استعمال ہو اور نئی درخواست نہ جائے تو نئی ہدایت اس تک پہنچتی ہی نہیں۔ اس لیے اسے کیش کی مکمل صفائی یا رازداری کے تحفظ کی کافی شرط نہ سمجھیں۔ پرانے نسخوں کی مدت اور اپنے زیرِ انتظام کیش کی تازہ کاری کا طریقہ بھی جانچیں۔
3. ETag اور 304 کے ساتھ ایک واپسی کا مرحلہ وار جائزہ
فرضی مثال میں /hours.json بند ہونے کا وقت 18:00 دیتا ہے۔ اگلا حصہ HTTP/1.1 کی مختصر مثال ہے جس میں صرف وضاحت کے لیے متعلقہ ہیڈرز رکھے گئے ہیں؛ حقیقی تبادلے میں درکار دوسری تفصیلات شامل نہیں۔ hours-v1 منتخب نمائندگی کے لیے رکھا گیا شناخت کنندہ ہے، وقت نکالنے کا فارمولا یا کسی حقیقی فائل کا حساب کیا ہوا ہیش نہیں۔
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-cache
ETag: "hours-v1"
{"closes":"18:00"}جو براؤزر یہ جواب محفوظ کر چکا ہو، وہ اگلی بار ETag کا شناخت کنندہ If-None-Match میں بھیج کر مشروط درخواست کر سکتا ہے۔ اگر شرط سرور کی موجودہ منتخب نمائندگی سے مطابقت رکھے اور نمائندگی نہ بدلی ہو تو سرور 304 Not Modified واپس دے سکتا ہے۔ اگلے حصے میں درخواست اور اس کے بعد جواب کا مختصر ریکارڈ ہے؛ اس کا مطلب یہ نہیں کہ 304 کے جواب کے بعد نئی JSON باڈی بھیجی گئی ہے۔
GET /hours.json HTTP/1.1
Host: library.example
If-None-Match: "hours-v1"
HTTP/1.1 304 Not Modified
Cache-Control: no-cache
ETag: "hours-v1"MDN کی ETag کی وضاحت کے مطابق کلائنٹ محفوظ باڈی استعمال کر سکتا ہے۔ 304 میں نئی باڈی نہیں ہوتی، لیکن درخواست اور توثیق کا مواصلاتی تبادلہ پھر بھی ہوتا ہے۔ اگر بند ہونے کا وقت 19:00 ہو جائے اور نمائندگی بدل جائے تو پرانی شرط کے ساتھ درخواست پر نئے مواد اور نئے شناخت کنندے والا 200 متوقع ہے۔ اس کا مطلب یہ نہیں کہ no-cache ہمیشہ 304 لوٹاتا ہے، یا سرور کو ڈیٹابیس دیکھنے کی ضرورت نہیں رہتی۔
مفید جانچ صرف اسٹیٹس کوڈ نہیں بلکہ مواد اور شناخت کنندے کا تعلق بھی دیکھتی ہے۔ باڈی بدلنے کے باوجود پرانا ETag بھیجنے سے غلط طور پر یہ توثیق ہو سکتی ہے کہ کچھ نہیں بدلا۔ باڈی وہی رہے مگر شناخت کنندہ ہر بار بدلتا رہے تو ضرورت سے زیادہ باڈیاں منتقل ہو سکتی ہیں۔ یہ سرور کے جواب بنانے کے طریقے اور منتخب نمائندگی کے باہمی تعلق کا معاملہ ہے؛ محض ETag ہیڈر کی موجودگی درست تازہ کاری کا ثبوت نہیں۔
4. بدلنے والی دستاویز اور نئے نام والی فائل میں فرق کریں
ایک ہی URL پر بدلنے والی دستاویز کی پالیسی اور مواد بدلنے پر نیا فائل نام پانے والے لوگو یا اسکرپٹ کی پالیسی لازماً یکساں نہیں ہو گی۔ logo.a1.png سے logo.b2.png پر جانے کے لیے نئی دستاویز کو بھی نئے URL کی طرف اشارہ کرنا چاہیے۔ فائل نام میں شناخت کنندہ شامل کرنے کے بعد اسی پرانی فائل کا مواد بدل دینا اس وعدے کو توڑتا ہے کہ پتہ مقررہ مواد کی شناخت کرتا ہے۔
صرف نئی فائل اپ لوڈ کرنے سے تمام زائرین فوراً اس کی درخواست نہیں کرتے۔ اگر براؤزر کو پہلے سے ملی HTML دستاویز میں پرانے لوگو کا پتہ ہے تو وہ اسی پرانے URL کو استعمال کر سکتا ہے۔ اسی لیے فائلوں کے کیش کے ساتھ دستاویز کی تازہ کاری کا راستہ بھی دیکھیں۔ سب کو ایک ہی محفوظ رکھنے کی مدت دینے کے بجائے ہر جواب کے لیے تازہ کاری کی قابلِ قبول تاخیر واضح کریں۔
نئی اشاعت کے دوران پرانی اور نئی دستاویزات بیک وقت موجود ہو سکتی ہیں۔ نئی دستاویز اس کی متعلقہ فائل تیار ہونے سے پہلے دکھا دی جائے، یا پرانی فائل بہت جلد حذف کر دی جائے، تو مختلف خرابیاں پیدا ہوتی ہیں۔ جانچیں کہ نئی دستاویز میں درج فائلیں دستیاب ہیں اور پرانے حوالوں والی فائلیں اب بھی کھلتی ہیں۔ نام بدلنا مفید ذریعہ ہے، مگر اس سے اشاعت کی ترتیب یا پرانے نسخے پر واپسی خودبخود حل نہیں ہوتی۔
5. Network پینل میں ایک وقت میں ایک مفروضہ جانچیں
پہلے وہ حالت ریکارڈ کریں جس میں براؤزر کو کیش استعمال کرنے کی اجازت ہو۔ درست درخواستی URL اور query string، اسکرین پر نظر آنے والے اوقات کا نسخہ، اسٹیٹس کوڈ، درخواست کا If-None-Match، اور جواب کے Cache-Control اور ETag نوٹ کریں۔ ہیڈروں کے ایک جیسے نام یہ بھلا سکتے ہیں کہ قدر کس نے بھیجی، اس لیے درخواست یا جواب کا رخ واضح لکھیں۔ Chrome کے Network پینل کی دستاویز میں Headers ٹیب سے معلومات دیکھنے کا طریقہ موجود ہے۔
| جانچ کی حالت | کیا ریکارڈ کریں | کس جلدباز نتیجے سے بچیں |
|---|---|---|
| انہی اوقات کی دوبارہ درخواست | مشروط درخواست، اسٹیٹس اور اسکرین کے اوقات | 304 کا مطلب ہے کہ کوئی مواصلاتی تبادلہ نہیں ہوا |
| پرانے اوقات بدلنے کے بعد درخواست | نئی باڈی، ETag اور اصل درخواستی URL | انتظامی صفحے پر محفوظ ہونے کا پیغام آیا ہے، اس لیے سب زائرین کو تازہ معلومات مل گئی ہیں |
| براؤزر کیش بند ہو | پہلی ڈاؤن لوڈ اور عام واپسی کا فرق | یہ نتیجہ عام واپسی کی رفتار ہی ظاہر کرتا ہے |
| Back بٹن سے واپسی | نئی درخواست گئی یا پچھلی اسکرین بحال ہوئی | صفحہ نظر آ رہا ہے، اس لیے لازماً نئی HTTP توثیق ہوئی ہے |
براؤزر کیش بند کرنے کی جانچ الگ کریں۔ Chrome میں Disable cache اس وقت لاگو ہوتا ہے جب DevTools کھلا ہو، اس لیے ٹول کے کھلے ہونے اور اس ترتیب، دونوں کو درج کریں۔ یہ پہلی ڈاؤن لوڈ سمجھنے میں مدد دیتا ہے، مگر عام واپسی میں محفوظ نسخے کے استعمال کی جانچ جیسا نہیں۔ اگر ترتیب کا حال لکھا نہ ہو تو ہر بار نئی ڈاؤن لوڈ دیکھ کر غلطی سے سمجھا جا سکتا ہے کہ کیش کام نہیں کر رہا۔ جانچ کی شرائط محفوظ رکھیں تاکہ دوبارہ کیش کی اجازت والی حالت میں لوٹ کر موازنہ کر سکیں۔
مشاہدے کے دوران بیک وقت کئی تبدیلیاں اور درخواستیں نہ کرنے سے وجہ محدود کرنا آسان ہوتا ہے۔ پہلے مواد بدلے بغیر واپسی دیکھیں، پھر وقت کی صرف ایک چیز بدل کر جواب کا فرق جانچیں۔ دستاویز کا URL، سرور کی ترتیب اور فائل نام اکٹھے بدلیں تو پتا لگانا مشکل ہو گا کہ نتیجہ کس تبدیلی سے آیا۔ متوقع 200 یا 304 نہ ملے تو مزید ترتیبات شامل کرنے سے پہلے اصل درخواست اور جواب دوبارہ پڑھیں۔
6. دوسرے محفوظ راستے اور تکمیل کے معیار بھی جانچیں
براؤزر کا HTTP کیش بند کرنے سے یہ فرض نہ کریں کہ سرور کے آگے CDN یا ایپلی کیشن کے دوسرے محفوظ راستے بھی ختم ہو گئے ہیں۔ الگ دیکھیں کہ service worker درخواست سنبھال رہا ہے یا نہیں، درمیانی سرور کون سا جواب چنتا ہے، اور ایپلی کیشن پہلے سے ملے ڈیٹا کو اسکرین پر برقرار رکھتی ہے یا نہیں۔ صرف ایک ہی URL دکھائی دینے سے تمام تہوں میں ایک ہی نسخہ استعمال ہونے کا گمان نہیں کرنا چاہیے۔
Back سے واپسی کو بھی نئی HTTP درخواست سے الگ جانچیں۔ براؤزر پچھلے سیشن کی اسکرین بحال کر رہا ہو تو no-cache کے باوجود متوقع دوبارہ توثیق کی درخواست نظر نہیں آ سکتی۔ فوراً اسے سرور کے ہیڈر نظرانداز کرنے کا ثبوت مان لینے سے غلط تشخیص ہو سکتی ہے۔ نئے نیویگیشن، دوبارہ لوڈ اور Back میں واقعی درخواست گئی یا نہیں، یہ الگ ریکارڈ کرنے سے مختلف مظاہر کو ایک مسئلہ نہیں سمجھا جائے گا۔
اوقاتِ کار کی مثال میں تکمیل کا معیار محض کیش ہٹ کی شرح نہیں ہے۔ دیکھیں کہ تبدیلی نہ ہونے پر محفوظ نسخہ درست استعمال ہو، تبدیلی کے بعد اجازت یافتہ وقت میں نئی معلومات دکھیں، اور جواب مناسب لوگوں کے ساتھ بانٹا جائے۔ تبدیلی اور مشاہدے کے اوقات، شرائط اور اصل باڈی درج کرنے سے دوسرا شخص اسی حالت کو دوبارہ بنا سکتا ہے۔ رفتار کے اعداد بہتر ہوں مگر غلط اوقات دیر تک دکھیں تو اصل ضرورت پوری نہیں ہوئی۔
عملی سروس میں استعمال سے پہلے ہر قسم کے جواب کی پالیسی اور تازہ کاری و سابقہ نسخے پر واپسی کے طریقے ساتھ دیکھیں۔ عوامی دستاویز کی کیش ہدایات کو ذاتی جواب میں نقل نہ کریں، اور کامیاب توثیق کو رسائی کے اختیار کی جانچ مکمل ہونا نہ سمجھیں۔ ہیڈرز محفوظ کرنے اور دوبارہ استعمال کے اصول بتانے کا ذریعہ ہیں۔ جب یہ بتایا جا سکے کہ کیا محفوظ ہوا، کون سی جانچ ہوئی، اور موجودہ اسکرین تک کیسے پہنچے، تو پرانی اسکرین کی وجہ زیادہ درست طور پر معلوم کی جا سکتی ہے۔