Изпращане на 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 грешка, след като маршрутът през проксито е работил правилно. Проверете статуса на отговора и изискванията на дестинацията: метод, тип съдържание, полета на формуляра, бисквитки и евентуален токен за заявка.

Предизвикателство за удостоверяване на прокси идва от проксито. Влизането в приложението или отхвърлен формуляр принадлежат на дестинацията. Пазете идентификационните им данни отделно. Добавянето на парола за дестинацията към конфигурацията на проксито не може да удовлетвори влизането в дестинацията.

Правилата за заглавки при препращане на Squid са друг възможен източник на объркване. Тяхната политика от страна на сървъра е отделна от изграждането на валиден POST в Ruby. Не променяйте правилата за заглавки на споделено прокси само защото формулярът е се провалил веднъж.

При повторни опити помислете дали първото подаване вече не е било обработено. Загубен отговор не е доказателство, че POST никога не е достигнал приложението.

Подобни статии