Scrapy-peto povas sukcese atingi Splash, dum la retumilo ene de Splash ankoraŭ bezonas malsaman eliran vojon. Ĉi tiuj estas du konektoj:

Scrapy → Splash API
Splash browser → forward proxy → website

Por unu prokurilo po vidaĵo, pasigu la argumenton proxy de la HTTP-API. Splash 3.5 dokumentas prokurilan URL-on kiel http://proxy.example:8080, aŭ nomon de agordita prokurila profilo. La URL-formo ankaŭ subtenas SOCKS5 kaj laŭvolajn akreditaĵojn.

Kiam unuopaj paĝaj rimedoj bezonas malsamajn finpunktojn, uzu execute-skripton kaj registru la elekton antaŭ navigado:

function main(splash, args)
  splash:on_request(function(request)
    local host = args.default_proxy
    if request.url == args.special_resource then
      host = args.special_proxy
    end
    request:set_proxy{host = host, port = 8080, type = 'HTTP'}
  end)

  assert(splash:go(args.url))
  return splash:html()
end

Pasigu default_proxy kaj special_proxy kiel gastigantajn nomojn, kaj special_resource kiel la precizan rimedan URL-on por aparte enkursigi. Anstataŭigu la ununuran ekzemplan pordon, kiam la du aŭskultantoj malsamas. Aliaj rimedoj ricevas la defaŭltan vojon. La HTTP-prokurila listo proponas finpunktajn kandidatojn por tiuj gastigantaj kaj portaj kampoj, kiam vojoj al publikaj rimedoj estas permesitaj kaj neniuj prokurilaj akreditaĵoj estas aplikataj al la kandidatoj.

La metodo request akceptas laŭvolajn kampojn username kaj password. Kun tipo HTTP, HTTPS-celoj uzas CONNECT tra tiu HTTP-prokurilo; ili ne postulas elpensitan HTTPS-prokurilan tipon.

La retrovoko ruliĝas antaŭ ĉiu peto. Ĝiaj metodoj request ne povas ŝanĝi peton post kiam ĝi estis sendita, kaj la retrovoko ne povas voki nesinkronajn Splash-metodojn kiel splash:go aŭ splash:wait.

Tenu la vojan elekton stabila, kiam la paĝo atendas unu seancon aŭ fontidenton. Hazarde asigni ĉiun bildon kaj API-peton al alia eliro povas produkti vidaĵon, kies petoj ne plu apartenas al unu kohera seanco.

Rilataj artikoloj