Keep the form's destination in the request and the proxy in the connection configuration. A proxy does not need a special form field containing the URL you want, unless you are using a particular website's web-proxy interface.

For Ruby's Net::HTTP, an explicit HTTP proxy can be supplied when creating the client:

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) }

The proxy is illustrative; HTTP candidates for permitted public-form tests are available in the HTTP proxy list. The form endpoint must be replaced with a service intended to accept the submission. Net::HTTP's proxy documentation also describes proxy credentials and environment-derived proxy settings.

Read the response before blaming the proxy

A server rejecting a form can produce an HTTP error after the proxy route has worked correctly. Check the response status and the requirements of the destination: method, content type, form fields, cookies, and any request token.

A proxy-authentication challenge comes from the proxy. An application login or rejected form belongs to the destination. Keep their credentials separate. Adding a destination password to the proxy configuration cannot satisfy the destination's login.

Squid forwarding-header rules are another possible source of confusion. Their server-side policy is separate from constructing a valid Ruby POST. Do not modify a shared proxy's header rules merely because the form failed once.

For retries, consider whether the first submission may already have been processed. A dropped response is not proof that a POST never reached the application.

Mikanda mikatakata