Behold formularens destination i anmodningen og proxyen i forbindelseskonfigurationen. En proxy har ikke brug for et særligt formularfelt med den URL, du ønsker, medmindre du bruger et bestemt websteds web-proxy-grænseflade.

For Rubys Net::HTTP kan en eksplicit HTTP-proxy angives, når klienten oprettes:

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

Proxyen er illustrativ; HTTP-kandidater til tilladte offentlige formularTests findes på listen over HTTP-proxyer. Formularens endpoint skal erstattes med en tjeneste, der er beregnet til at modtage indsendelsen. Net::HTTP's proxydokumentation beskriver også proxy-legitimationsoplysninger og proxyindstillinger udledt af miljøet.

Læs svaret, før du skyder skylden på proxyen

En server, der afviser en formular, kan producere en HTTP-fejl, efter at proxy-ruten har fungeret korrekt. Kontroller svarstatus og destinationens krav: metode, indholdstype, formularfelter, cookies og en eventuel anmodningstoken.

En proxy-godkendelsesudfordring kommer fra proxyen. Et applikationslogin eller en afvist formular hører til destinationen. Hold deres legitimationsoplysninger adskilt. At tilføje en destinationsadgangskode til proxykonfigurationen kan ikke opfylde destinationens login.

Squids videresendelsesheader-regler er en anden mulig kilde til forvirring. Deres serversidepolitik er adskilt fra at bygge en gyldig Ruby POST. Ændr ikke en delt proxys header-regler, blot fordi formularen fejlede én gang.

Ved gentagne forsøg bør du overveje, om den første indsendelse allerede kan være behandlet. Et tabt svar er ikke bevis for, at en POST aldrig nåede applikationen.

Relaterede artikler