کیا Squid کا URL دوبارہ لکھنے والا جوابات کے بنیادی حصے بدل سکتا ہے؟
فارورڈ پراکسی کو بڑھاتے وقت درخواست URL کا انتخاب جواب کی موافقت اور TLS ڈکرپشن سے الگ رکھیں۔
url_rewrite_program درخواست URL کے فیصلوں پر کام کرتا ہے۔ یہ درخواست کی معلومات لیتا ہے اور Squid کے معاون پروٹوکول کے ذریعے جواب دیتا ہے؛ یہ ڈاؤن لوڈ شدہ فائل لے کر اس میں ترمیم کر کے واپس نہیں بھیجتا۔
| مطلوبہ عمل | متعلقہ حد |
|---|---|
| براؤزر کو ری ڈائریکٹ کرنا یا کوئی دوسرا درخواست URL چننا | درخواست کے مرحلے میں URL دوبارہ لکھنے والے معاون کا کردار |
| نظر آنے والے HTTP جواب کے بنیادی حصے کو بدلنا | جواب کی موافقت کا ذریعہ، جیسے تشکیل شدہ ICAP جواب کی تبدیلی |
| عام CONNECT کے اندر HTTP پڑھنا | پہلے منزل کا TLS مناسب تعیناتی ترتیب کے تحت ختم کرنا ہوگا |
| کسی ایپلیکیشن سے خفیہ کردہ فائل کو ڈکرپٹ کرنا | فائل کی ساخت، الگورتھم اور کلید، قطع نظر اس کے کہ وہ کیسے منتقل ہو |
آخری دو قطاریں آسانی سے مل جاتی ہیں۔ HTTPS پر منتقل ہونے والی عام فائل TLS سے محفوظ ہوتی ہے۔ ایپلیکیشن سے خفیہ کردہ فائل HTTPS ختم ہونے کے بعد بھی خفیہ رہ سکتی ہے۔ موافقت کا انٹرفیس چننے سے نہ ایپلیکیشن کی کلید ملتی ہے اور نہ اس کا ڈکرپشن الگورتھم۔
عام CONNECT خفیہ کردہ ٹنل بائٹس آگے بھیجتا ہے۔ URL معاون اندرونی جواب ظاہر نہیں کرتا؛ معائنہ درکار ڈیزائن کو طے کرنا ہوگا کہ یہ ٹریفک تعیناتی میں ڈکرپٹ ہو سکتا ہے یا ہونا چاہیے۔
جہاں Squid HTTP پیغام کا معائنہ کر سکتا ہے، وہاں جواب کی تبدیلی کی سروس اب بھی مواد کی انکوڈنگ، بدلی ہوئی لمبائی اور ناکامی کے رویے کی ذمہ دار ہے۔ انٹرفیس کو تبدیلی کی تعریف کے بعد چنیں، چلتی ہوئی URL دوبارہ لکھنے کی مثال کو ایسے پروسیسنگ مرحلے تک بڑھانے کے بجائے جو اسے کبھی نہیں ملتا۔