A célhely az kérésben maradjon, a proxy pedig a kapcsolat konfigurációjában. A proxynak nincs szüksége külön űrlapmezőre a kívánt URL-lel, hacsak nem egy adott webhely webproxy-felületét használja.

A Ruby Net::HTTP esetében explicit HTTP-proxy adható meg az ügyfél létrehozásakor:

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

A proxy csak szemléltetés; az engedélyezett nyilvános űrlaptesztek HTTP-jelöltjei a HTTP-proxylistán érhetők el. Az űrlap végpontját le kell cserélni egy olyan szolgáltatásra, amelynek célja a beküldés fogadása. A Net::HTTP proxy-dokumentációja a proxy-hitelesítő adatokat és a környezetből származó proxybeállításokat is leírja.

Olvassa el a választ, mielőtt a proxyt hibáztatja

Az űrlapot elutasító szerver HTTP-hibát adhat, miután a proxy útvonala megfelelően működött. Ellenőrizze a válasz állapotát és a célhely követelményeit: metódus, tartalomtípus, űrlapmezők, sütik és esetleges kéréstoken.

A proxy-hitelesítési kihívás a proxytól származik. Az alkalmazásba való bejelentkezés vagy az elutasított űrlap a célhelyhez tartozik. Tartsa külön a hitelesítő adataikat. A célhely jelszavának a proxy konfigurációjához adása nem teljesítheti a célhely bejelentkezését.

A Squid továbbítási fejlécszabályai egy másik lehetséges zavarforrás. A kiszolgálóoldali szabályzatuk különáll az érvényes Ruby POST felépítésétől. Ne módosítsa egy megosztott proxy fejlécszabályait csak azért, mert az űrlap egyszer meghiúsult.

Újrapróbálkozásnál fontolja meg, hogy az első beküldés már feldolgozásra kerülhetett. Az elveszett válasz nem bizonyítja, hogy a POST soha nem érte el az alkalmazást.

Kapcsolódó cikkek