Squid براؤزر سے کہہ سکتا ہے کہ منتخب HTTP URL کو HTTPS کے ذریعے دوبارہ آزمائے۔ منزل کو پہلے ہی متعلقہ وسیلہ HTTPS پر فراہم کرنا چاہیے؛ Raspberry Pi پر Squid چلانا ویب سائٹ پر وہ صلاحیت پیدا نہیں کرتا۔

Squid 7 کے url_rewrite_program انٹرفیس کے لیے، helper اس طرح کا کلائنٹ ری ڈائریکٹ واپس کر سکتا ہے:

OK status=307 url="https://www.example.com/help"

یہ مماثل درخواست کے لیے ایک مثالی helper جواب ہے، مکمل helper پروگرام نہیں۔ براؤزر ری ڈائریکٹ وصول کرتا ہے اور HTTPS URL پر نئی درخواست کرتا ہے۔ اپ گریڈ پالیسی سے باہر URL کو OK مل سکتا ہے اور وہ بدستور برقرار رہ سکتا ہے۔

HTTPS-قابل منزلوں کی معلوم فہرست استعمال کریں اور آنے والے URL کا تجزیہ کریں۔ مطلوبہ راستہ اور query محفوظ رکھیں، واضح پورٹس کا خیال رکھیں اور درخواست کے طریقوں کو سوچ سمجھ کر سنبھالیں۔ ہر http سابقے کو اندھا دھند بدلنا یہ فرض کرتا ہے کہ ہر اصل کے پاس مساوی HTTPS سروس ہے۔

helper کو نصب شدہ Squid ورژن کے پروٹوکول کے مطابق ہر ان پٹ لائن کا جواب دینا چاہیے۔ اگر بیک وقت helper چینل فعال ہوں تو جواب میں چینل شناخت کنندہ محفوظ رکھیں۔ پرانا ننگا 301:URL مثال موجودہ result-and-key/value فارمیٹ کے ساتھ قابل تبادلہ نہیں ہے۔

جب براؤزر کو نیا URL معلوم ہونا چاہیے تو کلائنٹ ری ڈائریکٹ منتخب کریں۔ rewrite-url جواب اس کے بجائے Squid سے کہتا ہے کہ کلائنٹ کی اصل درخواست کے پیچھے کوئی دوسرا URL لائے، جو ایپلیکیشن کے URLs اور حالت کو متضاد چھوڑ سکتا ہے۔

ابتدائی HTTP درخواست helper کے ری ڈائریکٹ کرنے سے پہلے ہی Squid تک پہنچ چکی ہے۔ یہ پالیسی اس درخواست کو ماضی میں محفوظ نہیں کر سکتی۔ TLS اگلے HTTPS کنکشن پر شروع ہوتا ہے؛ صرف ایک CONNECT ٹنل کوئی انکرپشن فراہم نہیں کرتا۔

متعلقہ مضامین