felixlohmeier
commented
3 years ago Da ein Linkcheck nicht bei jeder Verarbeitung laufen sollte (oder zumindest nicht für die Gesamtdaten) ist es als separater Prozess außerhalb von OpenRefine doch ganz praktikabel, denke ich.
Lösung mit curl:
# http status code aller Links ermitteln
curl --parallel --silent --head --write-out "%{http_code} %{url_effective}\n" $(while read line; do echo "-o /dev/null $line"; done < links.txt) > linkcheck.log
# Logdatei auf status code != 2XX prüfen
if grep '^[^2]' linkcheck.log; then echo 1>&2 "Logdatei $PWD/linkcheck.log enthält problematische status codes!" && exit 1; fiLösung mit wget:
# http status code aller Links prüfen (bei Fehlern schlägt task wegen wget exit code 8 fehl)
wget --server-response --spider --quiet -i links.txt &> linkcheck.logcurl --parallel überfordert die Server. Linkcheck für OPUS Siegen schlägt nach einigen hundert Abfragen fehl. Auch die Reduzierung des Standardwerts von 50 auf 5 parallele Prozesse mit --parallel-max 5 schlägt noch fehl.
Implementierung also vorerst als neuer task siegen:linkcheck bzw. wuppertal:linkcheck mit curl (aber ohne Parallelisierung).
Günstig wäre ein Linkchecker innerhalb von OpenRefine, damit Datensätze mit fehlerhaften Direktlinks dokumentiert (templating export id + url mit filter auf code != 200) und gleich aussortiert werden können. Der bisherige Lösungsansatz, den HTTP status code mit Jython abzufragen ist ziemlich langsam (einige Minuten für 1.000 Links). Ich habe auf der OpenRefine-Mailingliste nach alternativen Lösungsvorschlägen gefragt: https://groups.google.com/g/openrefine/c/itFI2ktZAXw
Die aktuelle Lösung ist vorläufig auskommentiert:
Alternativ könnte ein link check auch mit
wget --spidernach der Validierung ansetzen.