Das Konzept, die in einem Artikel nicht funktionstüchtigen URL auf einen Abschnitt der Diskussionsseite zu schreiben, ist nicht auf der Höhe der Zeit.
- Bereits während des Botlaufs 2012 war dies kritisiert worden.
- Es verursacht vermeidbare Unruhe auf der Diskussionsseite.
- Problembeseitigungen, egal auf welche Weise, sollen manuell auf der Diskussionsseite in die Liste der Vorlagenparameter eingearbeitet werden – vermeidbarer Zusatzaufwand.
- Insbesondere die Massenverteilung in kurzer Zeit, später auch das Entfernen nicht mehr benötigter Abschnitte, womöglich die Löschung inzwschen geleerter Diskussionsseiten zur Wiederherstellung der redlink-Eigenschaft verursachen hohen Folgeaufwand und belästigen auf den Beobachtungslisten.
- Die einmal geschriebenen Angaben veralten nach einer gewissen Zeit; der Schreibvorgang auf die Diskussionsseiten einschließlich Löschung veralteter Abschnitte dauert vier Monate.
In den Jahren 2013/14 war das Labs/Tools-System noch nicht stabil gewesen; inzwischen ist es zumindest deutlich robuster geworden. Das Vorgängersystem Toolserver war für kleine Werkzeuge ausgelegt, die von Einzelbenutzern gewartet wurden und nach einem halben Jahr Untätigkeit gesperrt wurden.
Ein neues System soll:
- Für alle Wikis der WMF die Verfügbarkeit von URL, die in deren inhaltlichen Seiten vorkommen, in regelmäßigen Abständen vorsorglich prüfen und auf Nachfrage die momentane Verfügbarkeit für eine Seite auflisten; nebst zusätzlicher Hinweise.
- Ein interaktives Formular für menschliche Benutzer anbieten, eine Internet-Schnittstelle (API) für beliebige Werkzeuge und eine Labs-interne Abfrage für befreundete Labs-Tools (Bots) bereitstellen.
Anfrage-Möglichkeiten
BearbeitenInteraktiv
BearbeitenEin Formular wird jedem Internet-Benutzer angeboten. Eingegeben werden kann alternativ:
- Eine URL (zu einem Weblink)
- ein URL-Muster; Host-Komponenten, Beginn des Pfades; Platzhalter
- Ein Namensraum (alle Inhaltsnamensräume) in einem Wiki zur Filterung
- ein URL-Muster; Host-Komponenten, Beginn des Pfades; Platzhalter
- Die Bezeichnung einer Seite der WMF (Wiki, dazu entweder Seitenname oder Seitenkennummer) bzw. befreundeter Farm.
Außerdem eine Filterung nach Status (nur funktionierend, nur unerreichbar, zweifelhafte Funktion).
Schließlich ist neben der Analyse einer einzelnen URL/Seite auch die Ausgabe einiger projektweiter (per Wiki) Listen von URL gleicher Eigenschaften vorzusehen:
- Alle Seiten mit einer Spam-URL
- Alle Seiten mit unerreichbar/zweifelhaften URL oder URL-Muster einer bestimmten Domain und ggf. Pfad-Beginn, die zurzeit analysiert werden.
Die Antwort ist
- eine Liste aller URL der Seite mit problematischem Status, optional ergänzbar durch Hinweise zu Webarchiven und typischen Fehlerquellen sowie Spam-Blockade,
- auf Wunsch auch die vollständige Liste aller URL in dieser Seite mitsamt momentan bekanntem Status.
- Angezeigt werden die in dieser Sekunde vorhandenen URL; bei kürzlich erst eingefügten URL ist aber möglicherweise noch keine Vorgeschichte und keine Momentanverfügbarkeit bekannt. Aus anderen Seiten kann es aber bereits eine jahrelange Erfahrung geben.
- Weiterhin eine Liste anderer Seiten im selben Wiki, auf denen die URL oder das URL-Muster ebenfalls benutzt wurde; zumindest deren erste 50–100.
- Durch Vorlageneinbindungen kann diese Liste in die Tausende gehen.
- Da die Seiten erst mit einem gewissen Nachlauf analysiert werden, sind in der Liste anderer Seiten noch für einige Tage oder Wochen bereits reparierte Einträge vorhanden, was durchaus von Vorteil sein kann.
- Ggf. wäre eine Ausdehnung auf alle Wikis derselben Farm denkbar.
Die Anfrage nach URL-Analyse einer Wiki-Seite wird immer beantwortet; unabhängig davon, in welchem Namensraum oder welcher Kategorie sie stünde. Sofern sie URL enthält, über die zufällig Erkenntnisse vorliegen, werden diese Informationen auch mitgeteilt. Die interaktive/API-Anfrage zu einer Wiki-Seite löst aber keine Beobachtung der Seite und der darin enthaltenen URL aus; allerdings kann sie dem Seitencrawler übermittelt werden, der überprüfen mag, ob sie die Kriterien hinsichtlich Namensraum oder Kategorie erfüllt und künftig neu zu beobachten wäre.
Ein zusätzliches Formular ermöglicht nur interaktiv die Meldung von URL (und Domains mit kompletten Pfaden), die manuell erreichbar sind, aber fälschlich durch den Automatismus als defekt gezeigt werden.
- Die URL, auf die das zutrifft, werden behandelt wie jede andere auch, aber bei Anzeige der Nichterreichbarkeit wird ein zusätzlicher Hinweis gegeben.
- Sollte eine auf diese Weise gekennzeichnete URL eine reguläre Antwort auf die automatische Abfrage erhalten, wird der Eintrag sofort gelöscht.
- Sechs Monate nach dem interaktiven Hinweis wird dieser immer entfernt.
- Damit wird vermieden, dass ein falscher Status über die Jahre eingefroren wird. Benutzer müssen die Eigenschaft regelmäßig erneuern.
- Für eine interaktiv als trotzdem erreichbar gemeldete URL kann diese Eigenschaft auch jederzeit interaktiv wieder entfernt werden.
- Es muss vermieden werden, dass über die Meldungsfunktion Vandalismus betrieben wird, womöglich automatisch organisiert.
- Die Zahl der Meldungen pro interaktives Benutzerprofil ist auf eine pro Minute zu begrenzen.
- Die Zahl der Meldungen pro Tag über alle Benutzer ist auf einen realistischen Erfahrungswert von einigen Tausend zu begrenzen.
- Wenn für etwa die Hälfte aller URL einer Domain Meldungen vorliegen, sie seien manuell erreichbar, dann wird für die gesamte Domain für sechs Monate unterstellt, alle URL darin wären vermutlich erreichbar.
Ein weiteres Feld lässt die Hinterlegung von genau einer Ersatz-URL für eine nicht erreichbare URL zu.
- Diese Behauptungen aus der Community werden nur unter ausdrücklichem Vorbehalt in den Antworten angezeigt.
- Die Ersatz-URL wird erst dauerhaft gespeichert und angezeigt, nachdem sie auf Funktionalität geprüft wurde und problemlos arbeitet.
- Ob sie tatsächlich den gleichen Inhalt hat wie die ursprüngliche URL, liegt in der Verantwortung des Anwenders.
- Die Angabe kann auch von jedem Internetbenutzer wieder eliminiert werden.
- Falls es sich um eine Seite in einem bekannten Archiv handelt, erfolgt eine Eintragung in der separaten Liste, und nicht als auf eine URL begrenztem Alternativvorschlag.
Meldungen über einzelne URL oder URL-Muster werden nur entgegengenommen, wenn bereits ein Treffer in der Liste der bereits beobachteten URL vorhanden ist.
Die Benutzeroberfläche ist translatewiki-allsprachlich.
Es ist bewusst keine Möglichkeit vorgesehen, eine neue URL in das System einzubringen, ohne dass diese in einer ausgewerteten Seite eines Wiki der WMF (oder befreundeter Farmen) vorkommen würde.
- Andernfalls würde vielfältigen Missbrauchsmöglichkeiten für fremde Zwecke Vorschub geleistet.
Zusätzlich zum Datenbanknamen soll auch die Farm angehängt werden, wobei @WMF
die Vorgabe ist.
- Damit soll anderen Wiki-Farmen mit MediaWiki ermöglicht werden, ebenfalls von den Erkenntnissen zu profitieren.
- In Frage kommt
@wmflabs
zu Erprobungszwecken, Kooperationspartner wie OSM oder vielleicht auch Wikia. - Auskünfte zu weiteren Seiten mit gleicher URL sind grundsätzlich immer auf die eigene Farm beschränkt.
API
BearbeitenStatt mittels interaktivem Formular kann die Kennung einer Seite im Wiki über eine entsprechend codierte URL abgefragt werden. Anzugeben ist eine oder eine gewisse Anzahl von Seitenkennummern wie etwa
dbname=dewiki@WMF&curid=9301140
und ggf. auch Seitennamen.
Es muss mit unbefugter Nutzung durch Außenstehende gerechnet werden. Automatisierte Anfragen nach einzelnen URL werden deshalb nicht beantwortet.
Die Antwort erfolgt in den API-typischen Formaten JSON oder XML oder aber HTML wie bei einer interaktiven Anfrage.
Die Abfrage kann auch auf ein reines ping für die fraglichen Seiten reduziert werden, ohne eine detaillierte Antwort zu erwarten, so dass die internen Aktualisierungen angestoßen werden.
Skripte können die maschinenlesbaren Formate auslesen und in einer Wiki-Seite verwerten.
Die zulässige Häufigkeit der Abfrage pro IP(-Range) sollte gedrosselt werden, so dass alle sinnvollen Frequenzen unterstützt werden, aber Angriffe nicht zur Überlastung der Server führen.
Intern
BearbeitenFür Werkzeuge innerhalb der Labs besteht (hoffentlich) kein Problem der missbräuchlichen Fremdnutzung, sodass keine Drosselung der Abfragehäufigkeit erforderlich ist.
Die gleiche Abfrage wie als API kann Bot-artig für Namensräume von Wikis oder Kategoriebäume ausgelöst werden; insbesondere der Ping-Modus.
Ein separater Mechanismus (der als eigener Prozess laufen sollte und unabhängig programmiert werden kann) nimmt die regelmäßige Einspeisung neuer Kombinationen dbname@farm:pageid in das System zu überwachender Seiten der WMF vor.
- Nur der interne Mechanismus hat das Recht und die Möglichkeit, eine dbname@farm:pageid in das eigentliche System einzubringen oder zu entfernen.
- Gelöschte Seiten könnten mitgeteilt werden; trifft das Hauptsystem bei einem Überwachungslauf allerdings auf eine gelöschte Seite, dann entfernt es diese selbsttätig aus der Datenbank.
- Nur Seiten mit Inhaltsmodell
wikitext
werden in die Datenbank aufgenommen. - Die Kommunikation mit interessierten Menschen, in welchen Wikis welche Namensräume oder Kategoriebäume oder auch einzelne Seiten hinsichtlich URL analysiert werden sollen, ist vollständig vom Analysesystem zu trennen.
- In geeigneten zeitlichen Perioden können für jedes Wiki alle neu angelegten oder wiederhergestellten Seiten ab dem letzten relevanten Zeitpunkt aufgelistet, gefiltert und dem Analysesystem gemeldet werden; gleichfalls neu in Kategoriebäumen erscheinende Seiten.
- Im Prinzip ist auch zu ermöglichen, Bezeichner existierender Seiten ebenfalls wieder aus dem Analysesystem zu entlassen.
- Für eine Seite, die einmal in einem Kategoriebaum vorkam, ist primär keine Möglichkeit zur Entfernung beabsichtigt.
- Um eine Seite aus der Analyse zu entfernen, müssen alle zu diesem Wiki definierten Einschlusskriterien abgeprüft werden.
- Der zeitliche Ablauf ist untergeordnet. Bis zu einer URL die allererste Abfrage erfolgt, können Wochen vergehen; bis über eine Nichterreichbarkeit eine gesicherte Grundlage vorliegt, dauert es Monate. Bis über eine neu angelegte Seite und deren zuvor nie gesehene URL Erkenntnisse angezeigt werden können, mag es also immer eine Weile dauern.
Problem: Zeitlicher Vorlauf
BearbeitenWürde erst im Moment der Anfrage zu einer Seite damit begonnen, womöglich über hundert URL in der Seite abzufragen, und dann gar eine Antwort in der nächsten Sekunde erwartet werden, so muss das versagen:
- Es dauert Zeit, bis jeder angefragte fremde Server geruht, eine Antwort zu senden.
- Ein fremder Server kann für einige Minuten überlastet oder abgeschaltet sein; Dokumente können wegen einer vorübergehend kaputten Festplatte für einige Tage nicht erreichbar sein.
Das würde zur falschen Einschätzung führen, dass eine URL defekt sei, im Sinne einer dauerhaften Nichterreichbarkeit. Nun würde völlig sinnlos begonnen, dass Autoren Ersatz dafür suchen, und womöglich eine anscheinend nicht belegte enzyklopädische Aussage aus einem Artikel entfernt wird.
Tatsächlich bedarf eine gesicherte Anzeige nicht mehr verfügbarer URL mehrerer Wochen Vorlauf, um später Anfragen qualifiziert beantworten zu können.
Problem: Inhaltliche Eignung
BearbeitenAutomatische Prozesse können die mutmaßliche Erreichbarkeit einer URL oder die Nichterreichbarkeit registrieren.
Im Fall der Erreichbarkeit ist aber nicht gesagt, dass der Inhalt noch der gleiche oder ähnlich dem ist, der gesehen wurde, als der Weblink eingefügt wurde.
Es könnte auch schlicht auf der Seite stehen:
Diese Domain steht zum Verkauf. Überweisen Sie 1000 Dollar an ...
Archive
BearbeitenBekannte Hinterlegungen in Archiven sind ebenfalls mit der jeweiligen URL zu verknüpfen.
Dabei wird pro Archivtyp jeweils genau eine bestimmte Versionsbezeichnung hinterlegt, von der anzunehmen ist, dass sie das Ergebnis eines Aufrufs der URL zu allen Zeiten gut wiedergibt; ist zwar eine Archivierung erfolgt, jedoch noch keine bestimmte Version ausgewählt worden, wäre eine leere Zeichenkette etc. zu speichern.
Webseiten, die permanent ihren Inhalt ändern, eignen sich nicht für einen statischen Zugriff mittels URL; mindestens nicht für eine Empfehlung bestimmter Archivseiten durch das Werkzeug. Hier ist die Auswahl bestimmter Versionen manuell zu blockieren, was nur administrativ aufgehoben werden könnte.
Bereits einmal archivierte Webseiten können auch nachträglich wieder depubliziert werden; müssen sich also auch nachträglich aus den Vorschlägen des Werkzeugs entfernen lassen. Das soll automatisch durch vierteljährliche Routinebesuche gesichert werden.
Innere Abläufe
BearbeitenVorgesehen ist im Groben folgender Prozess:
- Sobald ein Name einer Wiki-Seite abgefordert wird, wird er in die verschiebungsresistente pageid gewandelt; für die interaktive Anzeige zur pageid der momentane Seitenname dargestellt.
- Sobald eine Wiki-Seite aktiv abgefordert wird, wird geprüft, ob sie die Bedingungen für Namensräume und Kategorien im Wiki erfüllt; falls ja, ob bereits eine Kombination Wiki-Name+pageid in der weltweiten Liste aller beobachteten Seiten eingetragen ist.
- Falls kein Eintrag vorhanden war, wird er neu angelegt.
- Im Vollausbau muss mit bis zu 100 Millionen interessanter Seiten gerechnet werden; zumindest 10 Millionen betreuter Seiten sind schnell erreicht.
- Falls am heutigen Kalendertag noch kein Datumsstempel für aktive Anfragen registriert worden war, wird er aktualisiert.
- Turnusmäßig geschieht im Rahmen der Kapazitäten Folgendes mit den von außerhalb vorgegebenen Konfigurationen für Namensräume und Kategorien zu jedem Wiki (Standard: Hauptnamensraum jeder Wiki-DB, die in die Konfiguration eingetragen ist); weitere Einschluss- und anschließende Ausschlusskriterien sind vorstellbar (Vorlagen, Wikidata-Eigenschaften):
- Alle ein oder zwei Wochen wird der Status aller beobachteten Namensräume und Kategorien im Wiki abgefragt, und jede davon erfasste pageid wird besucht:
- Der page record zu dieser Wiki-Seite erhält ein “touch” mit der passiven Tagesnummer.
- Ein Flag für erforderliche URL-Analysen wird gesetzt.
- Nachdem für alle Wikis die aktuellen Konfigurationen für Namensräume und Kategorien abgerbeitet wurden, werden nun alle page records besucht:
- Falls die Seite im Wiki in diesem Moment gelöscht gewesen ist, wird der Eintrag zur Wiki-Seite gelöscht.
- Falls der letzte “touch” älter als einige Monate ist, hat das Wiki das Interesse an dieser Seite verloren, sie wurde vielleicht in einen anderen Namensraum verschoben oder entkategorisiert, und der Eintrag wird jetzt gelöscht.
- Kurzzeitige Umkategorisierungen und vorübergehende Verschiebungen in andere Namensräume werden von diesem System ignoriert.
- Falls der Flag für erforderliche URL-Analysen gesetzt worden war, wird er zurückgesetzt und die aktuelle Menge der URL wird abgefragt, und diese werden wie auch bei einer interaktiven Anfrage ggf. der Menge der beobachteten URL hinzugefügt.
- Die URL werden normalisiert.
- Beispieldomains wie
example.org
sind gesondert einzustufen und brauchen nicht angefragt werden. - Syntaktisch falsche URL sind gesondert einzustufen und brauchen nicht angefragt werden.
- Die Rückverweise, welche URL von diesem page record benutzt werden, sind zu aktualisieren (zunächst zu löschen). Damit entsteht bewusst ein lag von einigen Tagen oder Wochen, die noch Hinweise liefert, wo kürzlich eine URL verwendet worden war, selbst wenn sie in der momentanen Seitenversion nicht mehr auftritt. Dies kann genutzt werden, um in der Versionsgeschichte kürzliche Fixe nachzuvollziehen.
- Für jede der aktuell vorhandenen URL wird der Datumsstempel der URL für Aktualisierungsbedarf auf den heutigen Tag gesetzt, und es wird wieder ein aktueller Rückverweis von der URL auf den page record eingetragen.
- Der Datumsstempel für passive Updates der Wiki-Seite wird aktualisiert; das heißt um die vorgesehene Periode ab dem heutigen Tag vergrößert.
- Bei entsprechend großer Anzahl von Wiki-Seiten könnte theoretisch der Fall eintreten, dass der Zeitbedarf für das Abfragen aller Wiki-Projekte größer wird als die vorgesehene Periode; dann kommt es schlicht zu einer Dauerschleife, bei der die am längsten zurückliegenden passiven Abfragen aktualisiert werden.
- Zusammengefasst könnte man die Aufnahme einer Wiki-Seite als eine Art Beobachtung dieser Seite auffassen.
- Alle ein oder zwei Wochen wird der Status aller beobachteten Namensräume und Kategorien im Wiki abgefragt, und jede davon erfasste pageid wird besucht:
- Wenn der Zeitraum für einen Durchgang vier Wochen übersteigt, ist Neuaufbau des Systems mit zusätzlichen Ressourcen (Hardware, Netzwerk) erforderlich.
- Für die Liste aller bekannten URL gilt folgende Prozedur:
- Sie wird nach Datumsstempel für Aktualisierungsbedarf sortiert.
- Diejenigen Einträge, die deutlich älter sind als die Umlaufzeit für Wiki-Seiten zuzüglich Ausfallzeiten, also vor zwei oder drei Monaten zuletzt abgefordert wurden, werden gelöscht.
- Sie kommen auf keiner aktiven Seite mehr vor.
- Sie waren vielleicht kaputt gewesen oder wertloser Spam und wurden überall ersetzt, oder enthalten jetzt etwas wie domain for sale.
- Sie belasten das Crawler-System nutzlos.
- Diejenigen URL, die noch nie kontaktiert wurden, werden initial belegt.
- Danach wird, beginnend mit dem ältesten Abruftag, jede URL angefragt, bis zu eine Minute gewartet und das Ergebnis verbucht. Letzter Abruftag ist der heutige Tag.
- Die Reihenfolge soll sich zufällig über den gesamten Durchlauf verteilen und nicht nach Domains sortiert werden. Oft blockieren Domains, wenn sie schnell hintereinander von der gleichen IP und UA-Kennung kontaktiert werden.
Auch hier gilt: Wenn die Umlaufzeit für einen Durchgang über vier Wochen steigt, ist eine physische Systemerweiterung erforderlich.
Größenbetrachtung
Bearbeiten- Für eine Handvoll der größten Wikipedien kommen zehn Millionen Artikel zusammen.
- Die Systemkapazität ist auf hundert Millionen Seiten auszulegen.
- Die Rate von unterschiedlichen aktiven URL pro Artikel liegt in der deutschsprachigen Wikipedia bei etwa drei (Schnappschuss: 5.584.413 aktive URL in 1.879.178 Artikeln).
- Somit wird mit vielleicht fünfzig Millionen URL für die größten Wikipedien begonnen; einmal aufgenommene URL verweilen sicher ein halbes Jahr im System, selbst wenn sie nur kurzlebig in einem Artikel erschienen waren.
- Netzwerkverkehr muss mit einer halben Milliarde URL rechnen, selbst wenn das erst im Vollausbau über alle Wikis erreicht wird.
- Ein Monat hat zweieinhalb Millionen Sekunden, gelegentliche Ausfallzeiten des Systems einmal abgezogen.
- Um jede von fünfzig Millionen URL einmal im Monat zu kontaktieren, sind 20 Abfragen pro Sekunde auszuführen.
- Wenn jede Abfrage bis zu einer Minute Antwortzeit erlaubt (die meisten antworten sehr viel schneller), wären über 1000 Connections offen zu halten und simultan zu bedienen.
- Das System muss aber 20 Statusmeldungen pro Sekunde verdauen und einarbeiten können; bei maximaler Auslegungslast 200.
- Parallel zur Last von URL-Kontakten müssen die Abspeicherung in die Datenbank und die Beantwortung von Abfragen aus der Wiki-Welt zum Status bestimmter Wiki-Seiten oder einzelner URL beantwortet werden und ggf. neu in die Datenbank eingetragen werden; außerdem turnusmäßig die EL beobachteter Wiki-Seiten abgefragt werden.
- Die Größenbetrachtungen gehen vorrangig von Wikipedien aus, und den kleinen Schwesterprojekten. Hinzu kommt dann noch Wikidata, wo irgendwann mal URL als Belege für jede Einzelinformation gesammelt werden müssten, was in den zweistelligen Millionenbereich ginge, wobei auch diese URL mit einer Rate von vielleicht 10 % alle zwei Jahre unerreichbar würden.
Technische Details
BearbeitenHTTP
Bearbeiten- Die Anfragen sind zunächst als HTTP HEAD zu stellen.
- Die meisten Server werden das auch sinnvoll beantworten.
- Sinnvoll ist die Antwort dann, wenn sie MIME und Content-Length sowie einen Statuscode enthält.
- Einige wenige Server geben nur auf HTTP GET verwertbare Antworten.
- Hier ist die Anfrage mittels HTTP GET zu wiederholen.
- Die entsprechenden Domains sollten in einer Tabelle registriert und für 200 Tage nur noch per GET abgefragt werden; anschließend wird dieser Sonderstatus gelöscht und müsste ggf. erneut erworben werden.
- Die Anfrage muss Accept-Felder enthalten; namentlich
HTTP/1.0
Accept: */*
Accept-Language: *
Accept-Encoding: gzip, deflate
Connection: keep-alive
Cache-Control: max-age=0
- Es sollte ein expliziter
User-Agent
mit Kontaktadresse geschaffen werden und zur Eintragung in useragentstring.com gemeldet werden.
Es könnte Probleme mit https/http und Gültigkeit von Zertfikaten geben.
Protokoll und Domain
BearbeitenRessourcen-URL
BearbeitenEs werden nur URL der Protokolle http oder https, ftp, ftps usw. aufgenommen, bei denen im WWW eine Antwort möglich ist. URL wie etwa mailto:
haben keine Server-Verfügbarkeit und liefern keinen HTTP-Status.
Beispiel-Domains
BearbeitenDie in RFC 2606 aufgelisteten Domains wie example.org
werden nicht in die Liste der zu einer Seite gehörenden Domains aufgenommen.
Domain unerreichbar
BearbeitenWenn eine Anfrage einen plausiblen 502 etc. Code bzw. Netzwerkfehler liefert, ist davon auszugehen, dass alle offenen Anfragen dieses URL-Zyklus ebenfalls 502 etc. ergeben und unerreichbar sind; sie können sofort mit dem Tagesdatum und diesem Statuscode versehen werden und belasten den Netzwerktraffic nicht unnötig. Falls sich erweisen sollte, dass der Code 502 unzuverlässig vergeben wird, können auch mehrere dieser Antworten im Zyklus abgewartet werden.
Mit dem nächsten URL-Durchlauf wird wieder unvoreingenommen mit dieser Domain umgegangen. Vielleicht wurde die Stromrechnung inzwischen bezahlt.
Bei schweren Netzwerkfehlern auf DNS-Ebene (Domain nicht auflösbar) können für diesen Durchgang sofort alle URL der gleichen Domain als unerreichbar markiert werden. Beim nächsten Durchgang mag die Domain (wieder) registriert sein, oder ein Serverproblem der DNS wurde behoben.
Domain-Besonderheiten
BearbeitenFür auffällig werdende Domains und Subdomains ist eine Tabelle zu führen:
Art | Tagesnummer | |
---|---|---|
Erstbeobachtung | Zuletzt | |
Umschaltung von http nach https erforderlich (secure site) | ||
Umschaltung von https nach http erforderlich (kein gültiges Zertifikat) | ||
Anfrage mit HTTP GET statt HTTP HEAD erforderlich (nur intern) | ||
DNS-Fehler (Domain nicht registriert) | ||
Schwerer Server-Fehler (Server down, keine Antwort) |
Wenn der Tag der letzten Beobachtung 10–30 Tage zurück liegt, ist ein neuer Versuch zu unternehmen und die Tagesnummer zu aktualisieren.
- Ist die Eigenschaft nicht mehr gegeben, ist der Eintrag vollständig zu löschen.
- Wenn der Tag der letzten Beobachtung 100 Tage zurück liegt, werden entsprechende URL nicht mehr beobachtet, die Gültigkeit ist ungewiss und der Eintrag ist durch einen turnusmäßigen Wartungsprozess zu löschen.
Auf eine Domain bezogenene Eigenschaften gelten auch für alle Subdomains, aber Subdomains können individuelle Eigenschaften haben, die nicht auf andere Subdomains zutreffen.
Auch wenn über eine angefragte individuelle URL noch keine Erkenntnisse herangereift sind, können über mehr als 100 Tage seit Erstbeobachtung konsolidierte Informationen nach außen gegeben werden.
- Primär ist die Tabelle für den internen Gebrauch gedacht.
Domain-Syntax
BearbeitenDie Domain zu einer Ressource im www muss einige Bedingungen erfüllen. Die MediaWiki-Software markiert sie als Verlinkung und setzt sie auf die Liste der externen Links, auch wenn sie im www nicht erfolgreich sein kann.
Kriterien für ungültige authority parts (RFC 3986 etc.):
- unsichtbarer Unicode enthalten
- IPv4 mit ungültigen Zahlenwerten
- Wenn keine IP, dann Domain:
- Keine Trennung von TLD und 2nd level domain
- Domain-Komponente beginnt nicht mit Buchstabe oder aber endet nicht auf Buchstabe oder Ziffer
- port ungültig (keine ganze Zahl)
Beispiele für ungültige Domains:
http:///example.org
http://http://example.org/
http://docs/about.htm
[http://a document title http://example.org/and/this/is/the/URL]
http://example.com:8o8o/foo/bar
http://example.c/forget/it
Externe Links in einer Seite
BearbeitenDie externen Links in einer Seite sind aus zwei Datenbanktabellen zusammenzustellen:
- Direkt:
externallinks
als URL. - Indirekt:
iwlinks
Im zweiten Fall können nicht nur andere Wikis derselben Farm enthalten sein, sondern auch „Pseudo-Interwikis“
- Diese API-Abfrage enthält auch verborgen: https://dx.doi.org/10.1000/182
Die Special:Interwiki ist anscheinend für die geamte Farm identisch; wird zumindest für WMF zentral auf meta: gepflegt. Die zugehörige Tabelle interwiki
ist aber auch lokal in jedem Wiki vorhanden, aus dem verlinkt wird (API: interwikimap).
- Über Ersetzung von
$1
iniw_url
durchiwl_title
kann sofort die URL gebildet werden. Es isthttps
anzunehmen. - Das Flag
local
ist dabei wichtig:- Bei der Aufnahme von URL in die Tabelle der zu besuchenden URL sind die
local
zu ignorieren. - Bei der Auskunft über den Momentanstatus einer Seite (interaktiv/API) können diese URL spontan ausgewertet werden und dadurch ggf. Hinweise auf fehlende Zielseiten in anderen Wikis gegeben werden.
iw_wikiid
ermöglicht ggf. einen Direktzugriff.
- Bei der Aufnahme von URL in die Tabelle der zu besuchenden URL sind die
Analyse der URL einer Seite
BearbeitenWenn eine Seite im Wiki angesprochen wird, dann ist für sie die Liste der externen Links verfügbar, die die MediaWiki-Software erkannt hat.
Diese Liste ist sofort zu filtern, die URL zu klassifizieren:
- Ressourcen-URL – sonst ignorieren
- Domain syntaktisch gültig – sonst sofort als ungültig einstufen, keine Kontaktaufnahme mehr
- Die URL ist dann zu normalisieren.
- Dieser Schritt kann integriert mit der Gültigkeitsprüfung erfolgen.
- Beispiel-Domain – diese ignorieren
- Domain gehört zur eigenen Farm – diese im Prinzip ignorieren
- In den interaktiven und API-Antworten zu dieser Seite jedoch Erreichbarkeit prüfen, sofern ohnehin in den EL aufgelistet.
- Falls 404, dann Hinweis; jedoch keine Aufnahme in die URL-Tabelle.
- Globaler oder lokaler Spam in Farm und Wiki – sofort entsprechend einstufen, keine Kontaktaufnahme mehr von dieser Seite aus auslösen
Anmerkungen zu verdächtiger Syntax in path/query wie ein kodiertes bidirektionales Steuerzeichen können der URL sofort attribuiert werden.
URL-Normalisierung
BearbeitenAuf der EL sind die URL von MediaWiki bereits auf bestimmte Art und Weise einem Encoding und Escaping unterzogen worden. Um gleich wirksame URL nur genau einmal zu handhaben, ist eine zusätzliche Normalisierung vorzunehmen:
- Der Host-Anteil (insbesondere die Domain) sind in Kleinschreibung umzuwandeln.
- IDN sind als Punycode zu speichern; desgleichen ggf. im Pfad.
- Der Pfad besteht aus mindestens einem
/
.
Alle Normalisierungen durch Escaping sind präzise zu dokumentieren.
- Ein API-Zugang sollte zu einer beliebigen URL die normalisierte Form liefern.
- Wenn interaktiv Informationen zu einer URL angefragt werden, ist die Antwort unter Darstellung der normalisierten Form zu geben.
Syntaktisch falsche URL sind gesondert einzustufen und werden nicht standardisiert; sie erhalten auch keine Attribuierung und werden deshalb auch nicht in die Watchlist beobachteter URL aufgenommen.
Spam
BearbeitenDie URL werden mit der globalen Spam-Liste und der Spam-Liste des Wiki abgeglichen. Für Spam-URL werden keine Verfügbarkeitsabfragen ausgeführt.
- Eine URL, die lokal oder global geblockt ist, trägt zur Liste der URL nicht mit einer Aufforderung zur Verfügbarkeitsprüfung bei.
- Andere Verwendungen der geblockten Domain können im lokalen Wiki mit gewöhnlicher Weblinksuche gefunden werden.
Über lokale Blockierung auf anderen Wikis wird nicht informiert. Wenn die Admins auf einem der 1000 WMF-Wikis beschließen, die New York Times auf die Liste der verbotenen Hetzschriften zu setzen, würde sonst bei jeder Seite jedes Wiki jede Verlinkung als unerwünscht angezeigt werden.
Globale Blockierungen betreffen immer nur die Farm und sind keine Eigenschaft der URL als solcher.
Fehlerhafte Statuscodes
BearbeitenEs gibt Server, die falsche Fehlernummern (400er und 500er) zurückgeben. Anhand von Plusibilitätsbetrachtungen (500er haben nur geringe Größe) lassen sich einige Fehlermeldungen in der Einstufung korrigieren.
Eine 500er Antwort kann keinen Server und keinen MIME-Typ enthalten, und verschiedene andere Merkmale weisen darauf hin, dass sie vom Zielserver stammen.
Eine 400er Antwort kann eigentlich nur text/plain
oder text/html
sein; eine application
weist auf einen falschen Fehler hin.
Erreichbarkeitsgeschichte
BearbeitenSie ist das Kernstück des Auskunftsystems.
Zu jeder URL sind etwa drei bis fünf Einträge nach folgendem Muster gespeichert zu halten:
- Ein Byte mit dem Statuscode
- Tagesnummer, an dem dieser Statuscode zuerst beobachtet wurde
- Tagesnummer, an dem dieser Statuscode zuletzt beobachtet wurde
Zwischen beiden Tagesnummern hatten ausnahmslos alle Abfragen den identischen Statuscode geliefert.
- Der vorangehende Datensatz beschreibt einen anderen Statuscode mit der ersten und letzten Tagesnummer dieser Beobachtung.
- Eine Abweichung im jüngsten Statuscode schiebt irgendwann den ältesten Datensatz aus dem Gedächtnis heraus, wenn die Maximalzahl zulässiger Einträge überschritten wird.
Als „Statuscode“ wird nur ein Mapping der wenigen Dutzend standardisierter HTTP-Codes, Netzwerk-Codes und interner Kodierungen gespeichert; für die Kommunikation mit der Außenwelt auf 404, 305, 200, 502 usw. gemappt und für interaktive Abfragen um textliche Erläuterung ergänzt.
URL mit Besonderheiten
BearbeitenEs wird eine Tabelle für URL-Muster und Domains geführt, die allgemeine Auffälligkeiten protokolliert:
- example.org
- HTTP GET erforderlich
- Page moved (new URL) from 301–307
- Begrenzung der Anfragen pro Zeiteinheit
- Spam
- Zertifizierungsprobleme
- Domain ist manuell erreichbar, nicht aber durch Automatismus
- Abhängigkeit vom Referrer.
Die Einträge haben für jeweils ein halbes Jahr Gültigkeit und müssen danach aufgefrischt werden oder werden gelöscht.
URL mit Zusatzinformationen
BearbeitenBei jeder URL, für die das bekannt ist, wird ein Verweis auf Zusatzinformationen geführt. Dabei geht es um zwei Fälle:
- Von Standardressourcen abweichender MIME-Typ nebst Zahl der KiB.
- Archiv-URL bekannt.
- webcitation
- archive.org - Zweig
- …
Statusinfo
BearbeitenEs genügt ein Byte, um die für uns relevanten Statusinformationen zu speichern.
- Der HTTP-Statuscode deckt nicht alle relevanten Fälle ab.
- Er ist auch teilweise irrelevant.
- Der vom Server behauptete Statuscode kann offenkundig falsch oder unplausibel sein und von uns anders eingestuft werden. Die Typen 19, 20 und auch andere sind zu hinterfragen, ob nicht trotzdem eine Ressource abrufbar ist, und dann ggf. durch unseren Typ 7 zu ersetzen.
- Wenn mehr
Content-Length
vorhanden ist, als eine Fehlerseite erfordern würde, oder diese ungewöhnlichen MIME enthält, könnte der Statuscode irreführend sein.
- Wenn mehr
Type | HTTP | Issued by | Explanation |
---|---|---|---|
0 | – | us | No attempt yet. |
– | 100– | Server | Live; not recorded. |
1 | 200 304 |
Everything fine. | |
2 | 201–299 300 |
Content should be available on request in wiki page | |
7 | – | us | autocorrected HTTP status code; meaningless warning |
8 | 301 | Server | Moved Permanently (different URL recorded) |
9 | 302 | Found (different URL recorded) | |
10 | 303 | See Other (different URL recorded) | |
11 | 305 | Use Proxy (different URL recorded) | |
12 | 306 | Temporary Redirect (different URL recorded) | |
13 | 307 | Permanent Redirect (different URL recorded) | |
16 | 400 414 422 431 500 |
Syntax problem Server overload (thread quota exceeded) | |
17 | 401 402 403 407 451 |
Authentification required, no public access | |
18 | 404 | Not Found | |
19 | 406 | Not Acceptable (how comes?) | |
20 | 409 411 412 417 418 420 424 425 428 444 449 4** 506 508 |
Strange answer on such question; probably wrong code | |
21 | 410 | Gone | |
22 | 415 | Unsupported Media Type, but requested with */* | |
23 | 416 | Requested range not satisfiable | |
24 | 423 | Locked | |
25 | 510 | Not Extended | |
26 | (*) | Unknown Status Code | |
32 | 405 | Method Not Allowed | |
33 | 408 | Request Time-out | |
34 | 413 | Request Entity Too Large | |
35 | 426 | Upgrade Required | |
36 | 429 | Too Many Requests | |
37 | 431 | Request Header Fields Too Large | |
38 | 501 | Not Implemented (HTTP-HEAD → HTTP-GET?) | |
39 | 502 504 |
Bad Gateway (other local server down) | |
40 | 503 | Service Unavailable | |
41 | 505 | HTTP Version not supported | |
42 | 507 | Loop Detected | |
43 | 509 | Bandwidth Limit Exceeded | |
63 | – | us | Change between http and https etc., then fine (other URL record exists with details) |
64 | – | Network | General network problem. |
65 | DNS refused. | ||
66 | DNS answered: “Unknown domain”. | ||
67 | Host is IP and server does not respond | ||
128 | Syntax | us | URL accepted by MediaWiki but invalid |
Kalender
BearbeitenEs ist nicht erforderlich, jeden Datumsstempel mit einem vollen Datumsformat auszustatten.
- Vielmehr wäre es intern ausreichend, die Tage etwa ab 1. Januar 2017 zu zählen.
- 65535 Tage würden knapp bis an das Jahr 2200 heranreichen.
- Berechnungen von Fristen wären effizienter, Speicherplatz einzusparen.
- Nur für die Darstellung nach außen ist dies umzurechnen, wobei ohnehin oft nur Angaben wie „vor zwei Wochen“ oder „seit sechs Monaten“ oder „bereits vor mehr als zwei Jahren“ anzuzeigen sind; die genauen Kalendertage kommen in der Außendarstellung eigentlich nicht vor.
- Einmal täglich ist die aktuelle Tagesnummer global zu aktualisieren; der Rest sind Differenzen von Tagesnummern.
Über das Julianische Datum, ebenfalls eine Tageszählung, lässt sich die interne Tagesnummer in das Julianische Datum der Außenwelt und dieses dann über Standardfunktionen in eine Kalenderanzeige wandeln.
Farmen
BearbeitenUm die möglichen Farmen abzubilden, genügt eine kleine Ganzzahl.
Code | Meaning | |
---|---|---|
0 | wmflabs |
Test environment |
1 | WMF |
First productive wikis. Default assignment. |
2 | … | Good friend, etc. |
Es muss sowieso ein Mapping auf korrespondierende Server erfolgen; zu jeder Farm ist also auch eine Netzwerkadresse usw. erforderlich und eine Zeichenkette WMF
würde auch noch nicht zur Kontaktaufnahme führen.
Weiterhin muss der Eintrag zu jeder Farm auch ein Domain-Muster enthalten, das die Identifizierung von inneren Verlinkungen zu eigenen Seiten der Farm ermöglicht.
Code | Meaning | Internal Domain pattern |
---|---|---|
0 | wmflabs
|
\.beta\.wmflabs\.org$
|
1 | WMF
|
\bmediawiki|wik(?:i(?:books|data|media|news|pedia|quote|source|species|versity|voyage)|tionary)\.org$
|
Page watchlist
Bearbeitenprimary key | farm | dbname | pageid | day of last page touch | URL list needs update |
---|---|---|---|---|---|
binary, internal | int | string | int | int | boolean |
The page feeder bot is crawling about once a week through all wikis.
- For all pages in configured namespaces and categories the page watchlist is checked whether a record exists, otherwise it will be created now.
- For each page record the day of last page touch will be set, and URL list needs update becomes true.
- The result is a unified match of all current namespace and category members, or which inclusion and exclusion criteria and rules anyone invents later. Exclusion will finally clear the URL list needs update flag.
In a second run, all these page records will be inspected.
- Overaged records (not touched for longer period) and records of deleted pages will be deleted; also any other content model than
wikitext
. - For each record that needs URL updating all relevant URL on page EL will be inserted into the URL watchlist, if not yet present.
- They will be created with an empty history.
- In URL watchlist the day of last URL touch will be set on “today”.
- If local or global spam list matched, this will update a spam backtrace table of this URL rather than a request for www accessibility.
On interactive query of a certain page it might be checked whether that one matches namespace or category criteria of that wiki, and could be added right now.
- Otherwise that page might receive touching the same way as performed on regular base.
URL watchlist
Bearbeitenprimary key | binary, internal | Unique for scheme host port path+query. |
scheme | string | http , https , ftp , ftps , sftp etc.Resources only. |
host | string | Normalized downcased punycode. Domain or IP. |
port | int | 0 – not provided
|
path+query | string | As delivered by EL; at least /
|
day of last URL touch | int | Touched by page watchlist loop. An URL not touched for some 100 days by any page loop will be deleted from the list, including all dependencies. |
day of last website query | int | May be used for sorting the crawler loop; oldest entries first. Updated on dealing with this URL, successful or not. |
History record | binary | Three or five entries. From one entry to next a change in state is required; else the youngest entry tells about continous constant answers until today (day of last website query). |
MIME | int/string | Notable MIME type (unified, mapped, perhaps coded); mostly unrecorded. |
length | int | Only if MIME field provided. Full KiB. |
Archives | set | List of archive entries, if any; also human suggestion for replacement. |
URL/page cross reference
Bearbeitenprimary key of page entry | binary, internal |
primary key of URL entry | binary, internal |
Dieser Rückverweis gibt an, welche Seiten in den letzten Tagen oder Wochen ebenfalls eine bestimmte URL verwendet hatten.
Er ist nicht dazu vorgesehen, zu ermitteln, welche URL in einer bestimmten Seite auftreten. Hierzu ist ausschließlich die momentane Wiki-Seite betreffend EL abzufragen.
Bei interaktiven Anfragen können aus demselben Wiki, zumindest aus derselben Farm andere Seiten benannt werden, in denen diese URL ebenfalls vorkommt oder bis vor kurzem noch vorgekommen war.
Bei einer ungefähr wöchentlichen page loop werden alle Einträge zu dieser Seite gelöscht und durch die aktuellen URL ersetzt.
Trennung der Module
BearbeitenVerschiedene Teilaufgaben sollen durch unterschiedliche voneinander unabhängige Softwarekomponenten realisiert und nur durch API verbunden werden, so dass sie ggf. auf unterschiedlichen Hardwarekomponenten betrieben werden können:
- Datenbank und Selbstverwaltung (Kernfunktion)
- Krabbeln im www: Übermittlung von Statusinformationen an die Datenbank
- Einzelauskünfte zu einer Wiki-Seite:
- Interaktives Formular
- API-Zugang: Abfrage des Status aller URL der Seite.
- Dadurch implizite zufällige Aufnahme einer Wiki-Seite in das System, sofern keine Policy dem entgegenstünde.
- Massenhafte Einspeisung der pageid von Kategoriebäumen und Namensräumen einzelner Wiki-Projekte in die Datenbank; Einpflegen von Seitenlöschungen, Spam-Blacklists abbilden.
- Kommunikation mit Web-Archiven und dem dortigen Bestand an Seiten; mögliche Depublikation.
MIME
BearbeitenWenn ein Server mit einem ungewöhnlichen MIME-Typ antwortet, der zunächst nicht von einem klassischen Browser unterstützt wird, sondern die Erfordernis von Zusatzsoftware nahelegt, dann soll dies gesondert zu den Eigenschaften der URL vermerkt werden, damit in der Wiki-Seite den Lesern entsprechende Hinweise gegeben werden können. Nicht weiter vermerkt werden HTML, PNG, SVG, GIF usw. Da für unbekannte Typen auch keine spezifische Software empfohlen werden kann, werden alle nicht identifizierbaren Ressourcen als binary vermerkt; bevor diese Einstufung erfolgt, sollte aber das erste Dutzend Bytes auf wohlbekannte magic inspiziert und der Inhaltstyp ggf. angepasst werden.
Gleichzeitig mit einem speziellen MIME-Typ soll auch die Content-Length
in ganzen KiB registriert werden.
Server verwenden oft nicht den standardisierten MIME-Typ; die Antwort wird interpretiert und auf ein intern vereinheitlichtes Schlüsselwort abgebildet.
Observed MIME | Mapping |
---|---|
audio/mpeg | mpeg |
audio/ogg | ogg |
application/ogg | |
audio/mpeg4-generic | mpeg4 |
application/mp4 | |
application/mpg4 | |
application/rtf | rtf |
text/rtf | |
image/tiff | tiff |
image/vnd-djvu | djvu |
text/css | css |
text/csv | csv |
application/zip | zip |
application/x-zip | |
application/x-zip-compressed | |
application/gzip | gzip |
application/x-gzip | |
application/vnd.adobe.flash-movie | flash |
application/flash | |
application/x-flash | |
application/x-shockwave-flash | |
video/flash | |
video/x-flash | |
application/pdf | |
application/x-pdf | |
application/xpdf | |
application/PDF | |
application/acrobat | |
application/vnd.adobe.pdf | |
application/postscript | postscript |
application/vnd.microsoft.excel | msexcel |
application/vnd.msexcel | |
application/vnd.ms-excel | |
application/x-msexcel | |
application/msexcel | |
application/ms-excel | |
application/vnd.microsoft.mspowerpoint | mspowerpoint |
application/vnd.microsoft.powerpoint | |
application/vnd.ms-powerpoint | |
application/mspowerpoint | |
application/ms-powerpoint | |
application/vnd.microsoft.msword | msword |
application/vnd.microsoft.word | |
application/vnd.msword | |
application/vnd.ms-word | |
application/msword | |
application/ms-word | |
text/msword | |
text/ms-word | |
(various) | binary |
Wer kann das, wer macht das
Bearbeiten- Mitarbeit von Freiwilligen
- Gifti
- Dispenser hatte einmal ein ähnliches System auf dem Toolserver betrieben; scheint privat noch auszuwerten.
- Bot-Betreiber mit einschlägigen Erfahrungen, auch der enWP.
- User:Frog23/Dead Link Finder
- WMF
- WMDE – ggf. Mitwirkung
Die produktive Vollversion, die über Jahre zuverlässig rund um die Uhr arbeiten soll, wird unter dem Dach der WMF angesiedelt werden müssen.
- Die physische Kapazität eines normalen Labs-Projekt wird im Vollausbau überfordert sein.
- Es werden mehrere unabhängige Server nur für diese Aufgabe benötigt, die auch mit hinreichender Ausfallsicherheit permanent Anfragen beantworten sollen.
- Allein für den Crawler würde es sich vermutlich lohnen, ein eigenes Glasfaserkabel zu verbuddeln.
In Analogie zu Citoid, Graphoid oder schließlich Parsoid könnte das neue System „Weboid“ heißen.
Mock-Up
BearbeitenBasierend auf den 2015/2016 gesammelten Erkenntnissen über URL-Verfügbarkeit könnte ein experimentelles Werkzeug auch bereits produktiv eingesetzt werden.
Es soll noch nicht den vollen Umfang und die Architektur des geplanten Systems enthalten, kann aber bereits die wesentlichen Funktionen für Standardaufgaben anbieten.
Gemeinsam ist allen Anfragen, dass die Identifikation einer Wiki-Seite vorgegeben wird; das Ergebnis ist eine der Anforderung entsprechend formatierte Auflistung aller in der Wiki-Seite enthaltenen URL, ggf. reduziert auf diejenigen, über die Erkenntnisse vorliegen, und die jeweiligen Erkenntnisse zur URL.
- Gadget-Abfrage
- Über etwas wie
https://iw.toolforge.org/giftbot/externalLinkProblem?dbname=dewiki@WMF&pageid=9301140
kann mit einem Funktionsaufruf in aktivem JavaScript bedient werden, wobei diese Ergebnisse dann innerhalb der HTML-Ansicht der zugehörigen Wiki-Seite präsentiert werden. - Enthalten sind nur URL, die mutmaßlich nicht erreichbar sind.
- Format siehe: en:User:PerfektesChaos/js/externalLinkProblem/query
- Weil das Ergebnis als aktives JavaScript innerhalb der Zielseite ausgeführt werden soll, muss der gesamte auf den Labs ausgeführte Quellcode auch in genau dieser Version auf den Labs offengelegt werden, und es muss deutlich gemacht werden, wie diese Labs-Antwort daraus entsteht.
- Über etwas wie
- URL-Parameter: Seiteninformationen
- Über etwas wie
https://iw.toolforge.org/giftbot/externalLinkInfo?dbname=dewiki@WMF&pageid=9301140&lang=de
werden als HTML-Dokument in Form einer Liste<ul>
alle URL und die ggf. zugehörigen Erkenntnisse präsentiert. - Ein Steuerparameter regelt explizit, ob alle URL oder nur diejenigen mit Erkenntnissen gezeigt werden sollen; wenn nicht angegeben, dann nur diejenigen mit Erkenntnissen. Regelfall für „Erkenntnisse“ wäre die vermutete Nichterreichbarkeit.
- Ggf. wäre nach Domain und Pfad zu sortieren: die Domain nach TLD, 2nd level, 3rd level usw.; port, http/https; Pfad.
- Die Präsentation sollte auch in der Testphase schon wählbar deutsch/englisch erfolgen; ansonsten nur englisch, damit das Mock-Up international als Grundlage für eine Neuentwicklung durch WMF dienen kann und auf anderen Wikis probehalber eingesetzt werden könnte. Vorgabe ist deshalb englisch.
- Die Verlinkung ist geeignet, den Seiteninformationen jedes Artikels hinzugefügt zu werden.
- Über etwas wie
- Interaktives Formular
- Das Ergebnis ist genau die gleiche HTML-Präsentation.
- Hinzu kommt ein Formular zur Auswahl des Wikis, des Seitennamens oder der pageid, des Anzeigeumfangs und der Sprache.
- Über die URL können die Formularfelder vorbelegt werden.
- Das interaktive Formular kann auch Antwort auf die Anfrage nach einer durch URL-Parameter bereits spezifizierten gezielten Auswertung sein, die danach vom Leser modfiziert werden kann.
- Weiteres API-Format
- Bei Bedarf könnte für andere Software ein weiteres automatisch auslesbares Format mit den gleichen Informationen wie unter 1 und 2 hilfreich werden.
- In Frage kämen JSON, das identisch mit dem Kernstück von 1 ist; oder XML, das weitgehend identisch mit dem Kernstück von 2 wäre (jedoch mit anderen Elementnamen).
- Es empfiehlt sich also für beide Implementierungen eine offene Programmierung der eigentlichen Datenformatierung, die Mehrfachnutzung des Codes ermöglicht.