Skicka en Ruby Net::HTTP POST via en proxy
Konfigurera en Ruby HTTP-anslutning med en explicit proxy och skicka sedan formulärdata till destinationen.
Behåll formulärets destination i begäran och proxyn i anslutningskonfigurationen. En proxy behöver inget särskilt formulärfält med den URL du vill ha, om du inte använder en viss webbplats webbproxygränssnitt.
För Rubys Net::HTTP kan en explicit HTTP-proxy anges när klienten skapas:
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) }
Proxyn är illustrativ; HTTP-kandidater för tillåtna tester av offentliga formulär finns i listan över HTTP-proxyservrar. Formulärets slutpunkt måste ersättas med en tjänst avsedd att ta emot inskickningen. Net::HTTP:s proxydokumentation beskriver också proxyuppgifter och proxyinställningar som härleds från miljön.
Läs svaret innan du skyller på proxyn
En server som avvisar ett formulär kan producera ett HTTP-fel efter att proxyvägen har fungerat korrekt. Kontrollera svarets status och destinationens krav: metod, innehållstyp, formulärfält, cookies och en eventuell begärandetoken.
En proxyautentiseringsutmaning kommer från proxyn. En programinloggning eller ett avvisat formulär tillhör destinationen. Håll deras uppgifter åtskilda. Att lägga till ett destinationslösenord i proxykonfigurationen kan inte uppfylla destinationens inloggning.
Squids regler för vidarebefordringsrubriker är en annan möjlig källa till förvirring. Deras serversidpolicy är skild från att bygga en giltig Ruby POST. Ändra inte rubrikreglerna för en delad proxy bara för att formuläret misslyckades en gång.
Vid nya försök, överväg om den första inskickningen redan kan ha behandlats. Ett tappat svar är inte bevis för att en POST aldrig nådde programmet.