Ein Ruby-Net::HTTP-POST durch einen Proxy senden
Konfigurieren Sie eine Ruby-HTTP-Verbindung mit einem expliziten Proxy und senden Sie dann Formulardaten an das Ziel.
Das Ziel des Formulars gehört in die Anfrage, der Proxy in die Verbindungskonfiguration. Ein Proxy braucht kein spezielles Formularfeld mit der gewünschten URL, es sei denn, Sie nutzen die Web-Proxy-Oberfläche einer bestimmten Website.
Für Rubys Net::HTTP kann beim Erstellen des Clients ein expliziter HTTP-Proxy angegeben werden:
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) }
Der Proxy dient der Veranschaulichung; HTTP-Kandidaten für erlaubte Tests öffentlicher Formulare finden Sie in der HTTP-Proxy-Liste. Der Formular-Endpunkt muss durch einen Dienst ersetzt werden, der die Übermittlung annehmen soll. Die Proxy-Dokumentation von Net::HTTP beschreibt außerdem Proxy-Anmeldedaten und aus der Umgebung abgeleitete Proxy-Einstellungen.
Lesen Sie die Antwort, bevor Sie den Proxy beschuldigen
Ein Server, der ein Formular ablehnt, kann einen HTTP-Fehler erzeugen, nachdem die Proxy-Route korrekt funktioniert hat. Prüfen Sie den Antwortstatus und die Anforderungen des Ziels: Methode, Inhaltstyp, Formularfelder, Cookies und ein eventuelles Anfrage-Token.
Eine Proxy-Authentifizierungsaufforderung kommt vom Proxy. Eine Anwendungsanmeldung oder ein abgelehntes Formular gehört zum Ziel. Halten Sie die Anmeldedaten getrennt. Ein Zielpasswort in der Proxy-Konfiguration kann die Anmeldung am Ziel nicht erfüllen.
Squids Regeln für Weiterleitungs-Header sind eine weitere mögliche Verwechslungsquelle. Ihre serverseitige Richtlinie ist unabhängig vom Aufbau eines gültigen Ruby-POST. Ändern Sie die Header-Regeln eines gemeinsamen Proxys nicht, nur weil das Formular einmal fehlgeschlagen ist.
Prüfen Sie bei Wiederholungen, ob die erste Übermittlung möglicherweise bereits verarbeitet wurde. Eine verlorene Antwort ist kein Beweis dafür, dass ein POST die Anwendung nie erreicht hat.