प्रॉक्सी के माध्यम से Ruby Net::HTTP POST भेजें

फ़ॉर्म का गंतव्य अनुरोध में और प्रॉक्सी कनेक्शन कॉन्फ़िगरेशन में रखें। प्रॉक्सी को आपके इच्छित 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 कभी एप्लिकेशन तक नहीं पहुँचा।