ఫారమ్ గమ్యాన్ని అభ్యర్థనలో, ప్రాక్సీని కనెక్షన్ కాన్ఫిగరేషన్‌లో ఉంచండి. నిర్దిష్ట వెబ్‌సైట్ వెబ్-ప్రాక్సీ ఇంటర్‌ఫేస్‌ను ఉపయోగించకపోతే, మీకు కావలసిన 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 ఎప్పుడూ అప్లికేషన్‌ను చేరలేదనడానికి రుజువు కాదు.

సంబంధిత వ్యాసాలు