Enviar um POST de Ruby Net::HTTP através de um proxy

Configure uma conexão HTTP Ruby com um proxy explícito e depois envie os dados do formulário ao destino.

Mantenha o destino do formulário no pedido e o proxy na configuração da conexão. Um proxy não precisa de um campo de formulário especial com o URL pretendido, a menos que esteja a usar a interface de proxy web de um site específico.

Para o Net::HTTP do Ruby, pode fornecer-se um proxy HTTP explícito ao criar o cliente:

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

O proxy é ilustrativo; candidatos HTTP para testes de formulários públicos permitidos estão disponíveis na lista de proxies HTTP. O endpoint do formulário deve ser substituído por um serviço destinado a aceitar a submissão. A documentação do proxy do Net::HTTP também descreve credenciais de proxy e definições derivadas do ambiente.

Leia a resposta antes de culpar o proxy

Um servidor que rejeita um formulário pode produzir um erro HTTP depois de a rota pelo proxy ter funcionado corretamente. Verifique o estado da resposta e os requisitos do destino: método, tipo de conteúdo, campos do formulário, cookies e qualquer token de pedido.

Um desafio de autenticação do proxy vem do proxy. Um início de sessão na aplicação ou um formulário rejeitado pertencem ao destino. Mantenha as credenciais separadas. Adicionar a palavra-passe do destino à configuração do proxy não pode satisfazer o início de sessão no destino.

As regras de cabeçalhos de reencaminhamento do Squid são outra possível fonte de confusão. A sua política do lado do servidor é separada da construção de um POST Ruby válido. Não altere as regras de cabeçalhos de um proxy partilhado só porque o formulário falhou uma vez.

Para novas tentativas, considere se a primeira submissão já pode ter sido processada. Uma resposta perdida não prova que um POST nunca chegou à aplicação.

Artigos relacionados