Надсилання POST Ruby Net::HTTP через проксі

Налаштуйте HTTP-з'єднання Ruby з явним проксі, потім надішліть дані форми до призначення.

Призначення форми залишайте в запиті, а проксі — у конфігурації з'єднання. Проксі не потребує спеціального поля форми з потрібним URL, якщо ви не використовуєте веб-проксі-інтерфейс конкретного сайту.

Для Net::HTTP у Ruby явний 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 — ще одне можливе джерело плутанини. Їхня серверна політика відокремлена від побудови коректного POST Ruby. Не змінюйте правила заголовків спільного проксі лише тому, що форма один раз не спрацювала.

Під час повторних спроб зважайте, що перше надсилання могло вже бути оброблене. Втрачена відповідь не доводить, що POST так і не дійшов до застосунку.

Схожі статті