Squid থেকে নির্বাচিত HTTP অনুরোধ HTTPS-এ পুনর্নির্দেশ

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 উপসর্গ অন্ধভাবে বদলানো ধরে নেয় প্রতিটি origin-এর সমতুল্য HTTPS সেবা আছে।

helper-কে ইনস্টল করা Squid সংস্করণের প্রোটোকল ব্যবহার করে প্রতিটি ইনপুট লাইনের উত্তর দিতে হবে। সমান্তরাল helper চ্যানেল সক্রিয় থাকলে উত্তরে চ্যানেল শনাক্তকারী রাখুন। পুরোনো খালি 301:URL উদাহরণ বর্তমান result-and-key/value ফরম্যাটের সঙ্গে বিনিময়যোগ্য নয়।

ব্রাউজারের নতুন URL জানা দরকার হলে ক্লায়েন্ট রিডাইরেক্ট বেছে নিন। rewrite-url উত্তর বরং Squid-কে ক্লায়েন্টের মূল অনুরোধের পিছনে অন্য URL আনতে বলে, যা অ্যাপ্লিকেশন URL ও অবস্থা অসামঞ্জস্যপূর্ণ করে রাখতে পারে।

helper রিডাইরেক্ট করার আগেই প্রাথমিক HTTP অনুরোধ Squid-এ পৌঁছে গেছে। এই নীতি সেই অনুরোধকে পিছনের দিকে সুরক্ষা দিতে পারে না। TLS পরবর্তী HTTPS সংযোগে শুরু হয়; শুধু একটি CONNECT tunnel কোনো এনক্রিপশন দেয় না।