Probearje proxy-kandidaten mei aparte Ruby Net::HTTP-klanten

Meitsje ien Net::HTTP-eksimplaar per proxy-kandidaat en stop neffens it antwurd dat jo bewurking echt nedich hat.

In list mei proxys wurdt pas nuttich as elke poging in klant makket dy't foar dat einpunt konfigurearre is. Foar in GET fia net-autentisearre HTTP-proxys kin Net::HTTP sa brûkt wurde:

require 'net/http'

uri = URI('https://www.example.com/status')
proxies = ['http://proxy-a.example:8080',
           'http://proxy-b.example:8080']

proxies.each do |value|
  proxy = URI(value)
  http = Net::HTTP.new(uri.host, uri.port, proxy.host, proxy.port)
  http.use_ssl = uri.scheme == 'https'
  http.open_timeout = 5
  http.read_timeout = 10
  begin
    response = http.get(uri.request_uri)
    puts "#{proxy.host}:#{proxy.port} #{response.code}"
    break if response.is_a?(Net::HTTPSuccess)
  rescue Net::OpenTimeout, Net::ReadTimeout, SocketError, SystemCallError, IOError => error
    warn "#{proxy.host}:#{proxy.port} #{error.class}"
  end
end

It fjirde argumint kiest de proxy-poarte; uri.host en uri.port wize noch altyd it doel oan. Folje de beide foarbyldynfieringen út 'e HTTP-proxylist yn as jo in tastiene iepenbiere URL fia net-autentisearre HTTP-einpunten kontrolearje. request_uri behâldt syn paad en query. It foarbyld behannelt gewoane ferbinings- en lêsflaters en registrearret in HTTP-status as dy komt.

Hjir einiget elk 2xx-antwurd de syktocht. As jo bewurking in oar resultaat ferwachtet, definiearje dat kritearium dan eksplisyt. In trochstjoering bewiist net automatysk dat de winske side opfrege is.

Hâld automatyske werhelling passend by de metoade. In POST dy't nei it ferstjoeren fan syn lichem in timeout krijt, hat de fiere applikaasje miskien al feroare; opnij probearje fia in oare proxy kin dat effekt werhelje. It GET-foarbyld belooft gjin feilige werhelling fan willekeurige transaksjes.

Relatearre artikelen