ফর্মের গন্তব্য অনুরোধে এবং প্রক্সি সংযোগ কনফিগারেশনে রাখুন। প্রক্সির আপনার কাঙ্ক্ষিত URL ধারণকারী বিশেষ ফর্ম ফিল্ড দরকার নেই, যদি না আপনি কোনো নির্দিষ্ট ওয়েবসাইটের ওয়েব-প্রক্সি ইন্টারফেস ব্যবহার করেন।

Ruby-এর Net::HTTP-এর জন্য, ক্লায়েন্ট তৈরির সময় একটি স্পষ্ট HTTP প্রক্সি দেওয়া যায়:

require 'net/http'

uri = URI('https://example.com/form')
http = Net::HTTP.new(uri.hostname, uri.port,
                     '203.0.113.10', 8080)
http.use_ssl = true
http.open_timeout = 5
http.read_timeout = 10
request = Net::HTTP::Post.new(uri.request_uri)
request.set_form_data('message' => 'hello')
response = http.start { |session| session.request(request) }

প্রক্সিটি উদাহরণমাত্র; অনুমোদিত পাবলিক ফর্ম পরীক্ষার জন্য HTTP প্রার্থী HTTP প্রক্সি তালিকায় পাওয়া যায়। ফর্ম এন্ডপয়েন্টটি জমা গ্রহণের জন্য নির্দিষ্ট একটি সেবা দিয়ে প্রতিস্থাপন করতে হবে। Net::HTTP-এর প্রক্সি ডকুমেন্টেশন প্রক্সি শংসাপত্র এবং পরিবেশ থেকে প্রাপ্ত প্রক্সি সেটিংসও বর্ণনা করে।

প্রক্সিকে দোষ দেওয়ার আগে প্রতিক্রিয়া পড়ুন

ফর্ম প্রত্যাখ্যানকারী সার্ভার প্রক্সি পথ সঠিকভাবে কাজ করার পরেও HTTP ত্রুটি দিতে পারে। প্রতিক্রিয়ার অবস্থা এবং গন্তব্যের প্রয়োজনীয়তা যাচাই করুন: পদ্ধতি, কনটেন্ট টাইপ, ফর্ম ফিল্ড, কুকি এবং কোনো অনুরোধ টোকেন।

প্রক্সি প্রমাণীকরণের চ্যালেঞ্জ প্রক্সি থেকে আসে। অ্যাপ্লিকেশন লগইন বা প্রত্যাখ্যাত ফর্ম গন্তব্যের। তাদের শংসাপত্র আলাদা রাখুন। প্রক্সি কনফিগারেশনে গন্তব্যের পাসওয়ার্ড যোগ করলে গন্তব্যের লগইন মেটানো যায় না।

Squid-এর ফরওয়ার্ডিং-হেডার নিয়ম আরেকটি সম্ভাব্য বিভ্রান্তির উৎস। তাদের সার্ভার-সাইড নীতি বৈধ Ruby POST তৈরির থেকে আলাদা। ফর্ম একবার ব্যর্থ হওয়ার কারণে শেয়ার করা প্রক্সির হেডার নিয়ম বদলাবেন না।

পুনরায় চেষ্টার ক্ষেত্রে ভাবুন প্রথম জমাটি ইতিমধ্যে প্রক্রিয়া হয়ে থাকতে পারে কি না। হারানো প্রতিক্রিয়া প্রমাণ নয় যে POST কখনো অ্যাপ্লিকেশনে পৌঁছায়নি।

সম্পর্কিত নিবন্ধ