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.

Relaterade artiklar