Ruby の Net::HTTP POST をプロキシ経由で送信する
Ruby の HTTP 接続に明示的なプロキシを設定し、フォームデータを宛先へ送信します。
フォームの宛先はリクエストに、プロキシは接続設定に置きます。特定のサイトの Web プロキシ画面を使う場合を除き、プロキシに目的の URL を入れる特別なフォーム項目は不要です。
Ruby の Net::HTTP では、クライアントを作成するときに明示的な HTTP プロキシを指定できます。
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) }
プロキシはあくまで例です。許可された公開フォームのテストに使える HTTP の候補はHTTP プロキシ一覧にあります。フォームのエンドポイントは、送信を受け付けることを目的としたサービスに置き換える必要があります。Net::HTTP のプロキシのドキュメントには、プロキシの認証情報と環境から取得されるプロキシ設定も記載されています。
プロキシを責める前に応答を読む
フォームを拒否するサーバーは、プロキシ経由の経路が正しく機能した後でも HTTP エラーを返すことがあります。応答のステータスと宛先の要件を確認してください。メソッド、コンテンツタイプ、フォーム項目、Cookie、およびリクエストトークンです。
プロキシの認証要求はプロキシから来ます。アプリケーションのログインや拒否されたフォームは宛先に属します。両者の資格情報は分けて保持してください。宛先のパスワードをプロキシ設定に追加しても、宛先のログインは満たせません。
Squid の転送ヘッダーの規則も混乱の原因になり得ます。そのサーバー側のポリシーは、有効な Ruby の POST を組み立てることとは別です。フォームが一度失敗しただけで、共有プロキシのヘッダー規則を変更しないでください。
再試行では、最初の送信がすでに処理されている可能性を考えてください。応答が失われたことは、POST がアプリケーションに届かなかった証拠にはなりません。