alexvj
commented
5 years ago Confirmo que según estándares el 429 debe devolver una cabecera Retry-After. Sin embargo, muchos servidores no lo envían a propósito. En este caso, ResearchGate parece que se ampara en distintos CDNs o proxies intermediarios, uno de ellos es Cloudflare, quien envía el 429 desde uno de sus servidores y hace la comprobación del navegador/conexión antes de llevarte a una página, y lo hacen sin esta cabecera. Hay que hacer pruebas para tener una estimación de cuánto tiempo de espera establece.
El problema
Estoy recibiendo un 429 (too many requests) con cualquier intento con el scraper. Y con el navegador normal ResearchGate me hace una comprobación que dura unos segundos antes de dejarme entrar en cualquier página.
Posible solución
Se supone que los 429 suelen incorporar en su cabecera más información, entre ella cuánto se debe esperar para realizar otra petición. Investigaré un modo de leer las cabeceras, ver si aportan este dato, y en ese caso automatizar el scraper para que espere una cantidad adecuada en base a dicha información.
Cómo surgió el problema
Fue tras hacer pruebas sobre dos perfiles, los de Lluis Serra-Majem y Javier Sánchez. En total no habré hecho ni 10 peticiones y con un intervalo de par de minutos entre ellas.
No sé si lleva cuenta de peticiones acumuladas de otras pruebas de @BorjaZarco de estos días o qué, pero si esto pinta así de mal, las restricciones que tendremos con ResearchGate son severas.
Soluciones alternativas más extremas
Lanzar un navegador real y scrapear sobre él (integrar Selenium). El problema es si eso puede realizarse en el entorno donde se pretende lanzar el script. Por otra parte, no soluciona el problema en caso de que en algún momento aparezca un Captcha.
Red de proxies. En general esto soluciona la mayoría de problemas, pero puede requerir pasta.