फारमको गन्तव्य अनुरोधमा र प्रोक्सी जडान कन्फिगरेसनमा राख्नुहोस्। तपाईंले चाहेको 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 कहिल्यै एप्लिकेसनमा नपुगेको प्रमाण होइन।

सम्बन्धित लेखहरू