ફોર્મનું લક્ષ્ય વિનંતીમાં અને પ્રોક્સી કનેક્શન ગોઠવણીમાં રાખો. પ્રોક્સીને તમે ઇચ્છો તે 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 ક્યારેય એપ્લિકેશન સુધી પહોંચ્યું નહીં.

સંબંધિત લેખો