Stuur 'n Ruby Net::HTTP POST deur 'n proxy

Hou die vorm se bestemming in die versoek en die proxy in die verbindingskonfigurasie. 'n Proxy het nie 'n spesiale vormveld met die URL wat jy wil hê nodig nie, tensy jy 'n spesifieke webwerf se web-proxy-koppelvlak gebruik.

Vir Ruby se Net::HTTP kan 'n eksplisiete HTTP-proxy verskaf word wanneer die kliënt geskep word:

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) }

Die proxy is illustratief; HTTP-kandidate vir toegelate publieke vormtoetse is in die HTTP-proxylys beskikbaar. Die vorm-eindpunt moet deur 'n diens vervang word wat die indiening aanvaar. Net::HTTP se proxy-dokumentasie beskryf ook proxy-referensies en omgewingsafgeleide proxy-instellings.

Lees die antwoord voordat jy die proxy blameer

'n Bediener wat 'n vorm verwerp, kan 'n HTTP-fout lewer nadat die proxyroete korrek gewerk het. Kontroleer die antwoordstatus en die vereistes van die bestemming: metode, inhoudstipe, vormvelde, koekies en enige versoekteken.

'n proxy-verifikasie-uitdaging kom van die proxy. 'n Toepassing se aanmelding of 'n verwerpte vorm hoort by die bestemming. Hou hul geloofsbriewe apart. Om 'n bestemmingswagwoord by die proxykonfigurasie te voeg, kan nie die bestemming se aanmelding bevredig nie.

Squid se deurstuur-kopreëls is nog 'n moontlike bron van verwarring. Hul bedienerkant-beleid is apart van die bou van 'n geldige Ruby POST. Moenie 'n gedeelde proxy se kopreëls verander net omdat die vorm een keer gefaal het nie.

Oorweeg by herprobeer of die eerste indiening reeds verwerk kon gewees het. 'n Verlore antwoord is nie bewys dat 'n POST nooit die toepassing bereik het nie.