Qt HttpProxy বনাম HttpCachingProxy: CONNECT সক্ষমতা
Qt-এর CONNECT-সক্ষম HttpProxy-কে শুধু-অনুরোধ HttpCachingProxy ধরন থেকে আলাদা করুন।
Qt টানেল করতে সক্ষম একটি HTTP প্রক্সিকে তার শুধু-ক্যাশিং HTTP প্রক্সি ধরন থেকে আলাদা করে। দুটি নামেই HTTP আছে, কিন্তু তাদের সংযোগ সক্ষমতা ভিন্ন।
| Qt ধরন | সংযোগের ভূমিকা |
|---|---|
| HttpProxy | বহির্গামী TCP সংযোগের জন্য HTTP CONNECT সমর্থন |
| HttpCachingProxy | সামঞ্জস্যপূর্ণ অনুরোধ-ভিত্তিক ক্লায়েন্টে সাধারণ HTTP অনুরোধ |
| Socks5Proxy | এর নথিভুক্ত পরিবহন সক্ষমতাসহ SOCKS5 আলোচনা |
সাধারণ HTTP অনুরোধ করা একটি QNetworkAccessManager অনুরোধ-কেন্দ্রিক ধরনটি ব্যবহার করতে পারে। বাইট টানেল প্রয়োজন এমন QTcpSocket-এর জন্য TunnelingCapability আছে এমন প্রক্সি দরকার। সাধারণ TCP সকেটকে এটি ব্যবহার করতে হলে সেই সক্ষমতা ছাড়া অ্যাপ্লিকেশন ডিফল্ট ইনস্টল করার বিরুদ্ধে Qt বিশেষভাবে সতর্ক করে।
এন্ডপয়েন্ট নির্ধারণের আগে প্রোটোকল ধরন বেছে নিন। প্রক্সি প্রমাণীকরণ ছাড়া অনুমোদিত সাধারণ HTTP অনুরোধের জন্য HTTP প্রক্সি তালিকা ঠিকানা দেয়; Qt ধরনটিকে তবুও সেই অনুরোধের প্রয়োজনীয় সক্ষমতা দিতে হবে। HttpCachingProxy-কে CONNECT পরিষেবার ব্যবহৃত পোর্ট দিলে সেই Qt নির্বাচনে অনুপস্থিত সক্ষমতা যোগ হয় না।
শুধু-ক্যাশিং লেবেলটি এটাও প্রতিশ্রুতি দেয় না যে প্রতিটি প্রতিক্রিয়া দূরবর্তী সার্ভার সংরক্ষণ বা পুনরায় ব্যবহার করবে। এটি ক্লায়েন্ট ইন্টারফেসের সমর্থিত প্রক্সি ব্যবহারের ধরন বর্ণনা করে, আর HTTP প্রতিক্রিয়া নীতি ক্যাশ পুনর্ব্যবহার নিয়ন্ত্রণ করে।