Send en Ruby Net::HTTP POST gjennom en proxy
Konfigurer en Ruby HTTP-tilkobling med en eksplisitt proxy, og send deretter skjemadata til destinasjonen.
Hold skjemaets destinasjon i forespørselen og proxyen i tilkoblingskonfigurasjonen. En proxy trenger ikke et eget skjemafelt med URL-en du ønsker, med mindre du bruker web-proxygrensesnittet til et bestemt nettsted.
For Rubys Net::HTTP kan en eksplisitt HTTP-proxy angis når klienten opprettes:
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 for tillatte tester av offentlige skjemaer finnes i listen over HTTP-proxyer. Skjemaets endepunkt må erstattes med en tjeneste som er ment å ta imot innsendingen. Net::HTTPs proxydokumentasjon beskriver også proxy-legitimasjon og proxyinnstillinger utledet fra miljøet.
Les svaret før du klandrer proxyen
En server som avviser et skjema, kan produsere en HTTP-feil etter at proxy-ruten har fungert riktig. Kontroller svarbstatusen og destinasjonens krav: metode, innholdstype, skjemafelt, informasjonskapsler og en eventuell forespørselstoken.
En proxy-autentiseringsutfordring kommer fra proxyen. En applikasjonspålogging eller et avvist skjema tilhører destinasjonen. Hold legitimasjonen deres atskilt. Å legge til et destinasjonspassord i proxykonfigurasjonen kan ikke oppfylle destinasjonens pålogging.
Squids regler for videresendingsheadere er en annen mulig kilde til forvirring. Deres serversidepolitikk er atskilt fra å bygge en gyldig Ruby POST. Ikke endre headerreglene til en delt proxy bare fordi skjemaet feilet én gang.
Ved nye forsøk, vurder om den første innsendingen allerede kan være behandlet. Et tapt svar er ikke bevis for at en POST aldri nådde applikasjonen.