archive.today geht in manchen Browsern nicht mehr

[seth]

gudn tach!

wenn ich in firefox oder chromium https://archive.today/ aufrufe, dann wird die seite sofort (in weniger als einer sekunde) und anstandslos geladen.

wenn ich aber bei demselben request in firefox sage "copy as curl" und das in ein CLI einfuege, dann erhalte ich nach 1 minute die meldung

curl: (18) HTTP/2 stream 1 was not closed cleanly before end of the underlying stream

(das gleiche passiert beim simplen aufruf von curl https://archive.today/).

auch perls LWP::UserAgent steigt beim GET request mit einem 500er aus. und auch pythons requests-paket wirft eine exception: requests.exceptions.ConnectionError: ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response'))

dagegen liefert wget --user-agent='Mozilla' https://archive.md/kmcli einen 200er http-statuscode und laedt auch den html-content.

ich mag nicht in die untiefen des sourcecodes der programme einsteigen. sieht jemand von euch, woran das liegt, oder hat eine idee, wie man das leicht debuggen koennte?

das problem besteht schon seit mehreren tagen. ich vermute, dass serverseitig irgendwas verkorkst ist. aber da firefox/wget/chromium damit zurecht kommen, wuerde ich das verhalten gerne (insb. in perl) imitieren.

gruss

seth

[Felix Riesterer]

Lieber seth,

schön, Dich mal wieder hier zu haben!

dagegen liefert wget --user-agent='Mozilla' https://archive.md/kmcli einen 200er http-statuscode

Auf den ersten Blick sieht das für mich danach aus, dass Du einen „passenden“ User-Agent-String angeben musst. FF und Chrome tun das von sich aus und auch Dein WGet-Aufruf hat einen UA-String dabei. Bei Deinem cURL-Code und auch LWP-Beispiel sehe ich davon nichts.

Liebe Grüße

Felix Riesterer

[seth]

gudn tach!

schön, Dich mal wieder hier zu haben!

schoen, mal wieder hier zu sein und bekannte namen zu lesen! :-)

dagegen liefert wget --user-agent='Mozilla' https://archive.md/kmcli einen 200er http-statuscode

Auf den ersten Blick sieht das für mich danach aus, dass Du einen „passenden“ User-Agent-String angeben musst.

oh, pardon, das war ein copy-paste-relikt.

wget https://archive.today

geht einwandfrei (ohne manipulierten user-agent).

bei einer konkreten archivierten webpage, z.b. https://archive.md/kmcli muss ich dagegen den user-agent setzen, weil ich ansonsten einen http-status 429 (too many requests) zurueckbekomme. den status bekomme ich aber ohne verzoegerung zurueck.

das heisst: der user-agent hat mit dem genannten problem vermutlich nichts zu tun.

FF und Chrome tun das von sich aus und auch Dein WGet-Aufruf hat einen UA-String dabei. Bei Deinem cURL-Code und auch LWP-Beispiel sehe ich davon nichts.

curl --user-agent Mozilla https://archive.today/

liefert nach 1 minute wieder curl: (18) HTTP/2 stream 1 was not closed cleanly before end of the underlying stream.

gruss

seth

[Raketenwilli]

oh, pardon, das war ein copy-paste-relikt. wget https://archive.today geht einwandfrei (ohne manipulierten user-agent).

Nö.

wget https://archive.today
--2023-08-14 08:57:19--  https://archive.today/
Auflösen des Hostnamens archive.today (archive.today)… 198.23.187.186, 2606:4700::1117
Verbindungsaufbau zu archive.today (archive.today)|198.23.187.186|:443 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 429 Too Many Requests
2023-08-14 08:57:19 FEHLER 429: Too Many Requests.

dagegen liefert wget --user-agent='Mozilla' https://archive.md/kmcli einen 200er http-statuscode

Nö.

wget https://archive.md/kmcli
--2023-08-14 08:58:55--  https://archive.md/kmcli
Auflösen des Hostnamens archive.md (archive.md)… 192.210.214.166, 2606:4700::1117
Verbindungsaufbau zu archive.md (archive.md)|192.210.214.166|:443 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 429 Too Many Requests
2023-08-14 08:58:55 FEHLER 429: Too Many Requests.

Das waren meine ersten Aufrufe von der um 03:00 Uhr neu vergebenen IP…

Darüber hinaus sind die Fehlermeldugen (oder die Nichtreaktion gestern) ebenso wie die gelieferten IP-Adressen volatil. Die IP eben war von colocrossing, die sitzen in den USA.

Aber plötzlich liefert hosts eine andere IP als oben:

archive.today has address 178.250.243.66
   archive.md has address 178.250.243.66

(host: Einrückung von mir)

Es ist aber kein Round-Robin-Verfahren, dann würde ich mehrere IPs sehen, auch dig weicht im Ergebnis nicht ab.

Wenn ich die IP mit whois weiter untersuche, komme ich auf den vermuteten Standort:

inetnum:        178.250.240.0 - 178.250.243.255 ( kalkulierte CIDR: 178.250.240.0/22 )
netname:        MAJORDOMO-178-250-240
descr:          Majordomo VDS & Managed Hosting
country:        RU

Schauen wir mal auf die Route. (Befehl: mtr -u -c5 -r --show-ips -w '178.250.243.66'

Start: 2023-08-14T07:05:20+0000
HOST: raspi4.home                                                        Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- fritz.box (DSL-Router )                                             0.0%     5    0.8   0.8   0.7   0.9   0.1
  2.|-- loopback1.0001.acln.01.ham.de.net.telefonica.de 62.52.200.147     0.0%     5   14.7  26.1  14.2  44.5  16.1
  3.|-- bundle-ether27.0005.dbrx.01.ham.de.net.telefonica.de 62.53.12.12  0.0%     5   15.1  14.5  13.9  15.1   0.4
        bundle-ether27.0006.dbrx.01.ham.de.net.telefonica.de 62.53.12.14
  4.|-- ae5-0.0001.corx.06.ham.de.net.telefonica.de 62.53.14.232          0.0%     5   18.9  19.0  18.0  20.3   0.9
        ae4-0.0001.corx.06.ham.de.net.telefonica.de 62.53.14.230        
  5.|-- ae5-0.0002.corx.02.ber.de.net.telefonica.de 62.53.0.47            0.0%     5   18.8  21.1  17.9  25.8   3.3
  6.|-- ae21-0.0002.dbrx.02.ber.de.net.telefonica.de 62.53.0.101          0.0%     5   19.4  19.4  18.8  19.8   0.4
        bundle-ether3.0002.cord.01.ber.de.net.telefonica.de 62.53.25.244
        bundle-ether3.0001.cord.01.ber.de.net.telefonica.de 62.53.25.242
  7.|-- ae0-0.0002.prrx.02.ber.de.net.telefonica.de 62.53.12.59           0.0%     5   22.7  19.3  18.1  22.7   1.9
        ae1-0.0002.prrx.02.ber.de.net.telefonica.de 62.53.12.61         
  8.|-- retn.bcix.de 193.178.185.64                                       0.0%     5   20.2  19.0  18.3  20.2   0.8
  9.|-- ae1-3.RT.OK.MSK.RU.retn.net 139.45.243.1                          0.0%     5   55.5  54.3  44.4  73.5  11.7
 10.|-- 139.45.226.246                                                      0.0%     5   45.9  44.9  43.9  46.0   1.0
 11.|-- 217-67-176-53.in-addr.mastertelecom.ru 217.67.176.53              0.0%     5   53.1  52.9  52.3  53.6   0.5
 12.|-- 178-238-125-94.in-addr.mastertelecom.ru 178.238.125.94            0.0%     5   55.3  54.3  53.4  55.3   0.7
 13.|-- example.msk.ru 178.250.243.66                                     0.0%     5   53.7  53.7  53.5  54.1   0.2

Ja. Das ist logisch und physikalisch in Russland. Und wenn man der russischen Propaganda folgt, sind wir alle Faschisten, welche dem gottgleichen Wladimir Wladimirowitsch Putin sein Naturrecht auf die Weltherrschaft verweigern. Außerdem muss das Arschiv wohl immer mal bereinigt werden, damit dessen Inhalt zur Prawda (sehr spezielle russisch(e) „Wahrheit“) passt.

[Raketenwilli]

Aber plötzlich liefert hosts eine andere IP als oben:

archive.today has address 178.250.243.66
   archive.md has address 178.250.243.66

(host: Einrückung von mir)

Es ist aber kein Round-Robin-Verfahren, dann würde ich mehrere IPs sehen, auch dig weicht im Ergebnis nicht ab.

Nachtrag:

Die gelieferten IPs hämgen vom genutztem DNS ab. Warum Cloudflare mir eine IP aus Russland gibt (178.250.243.66), Google aktuell die 93.189.40.70, Yandex die 193.148.248.205, der „rekursive DNS“ von Neustar sodann die 90.156.209.190 weiß ich nicht und kann es auch argumentativ (Standort?) nicht nachvollziehen. Google und Cloudflare behaupten, nichts zu manipulieren.

Nachtrag zum Nachtrag:

fastix@mini:~$ dig archive.today @igan.archive.today

; <<>> DiG 9.18.16-1~deb12u1-Debian <<>> archive.today @igan.archive.today
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6710
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 9
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;archive.today.			IN	A

;; ANSWER SECTION:
archive.today.		300	IN	A	93.189.40.70

;; AUTHORITY SECTION:
archive.today.		86400	IN	NS	carl.archive.is.
archive.today.		86400	IN	NS	sara.archive.md.
archive.today.		86400	IN	NS	igan.archive.today.
archive.today.		86400	IN	NS	mick.archive.li.

;; ADDITIONAL SECTION:
carl.archive.is.	86400	IN	A	178.17.174.208
carl.archive.is.	86400	IN	AAAA	2a00:1dc0:caff:cc::
sara.archive.md.	86400	IN	A	94.140.114.194
sara.archive.md.	86400	IN	AAAA	2a02:7aa0:4000::3c
igan.archive.today.	86400	IN	A	23.184.48.154
igan.archive.today.	86400	IN	AAAA	2602:fc24:18:3d97::1
mick.archive.li.	86400	IN	A	5.188.6.118
mick.archive.li.	86400	IN	AAAA	2a03:90c0:275::33

;; Query time: 155 msec
;; SERVER: 23.184.48.154#53(igan.archive.today) (UDP)
;; WHEN: Mon Aug 14 09:46:17 CEST 2023
;; MSG SIZE  rcvd: 340

Bei der Überprüfung direkt auf den oben ersichtlichen, authorativen Nameservern mit

• dig archive.today @carl.archive.is
• dig archive.today @sara.archive.md
• dig archive.today @igan.archive.today
• dig archive.today @mick.archive.li

erhalte ich aktuell übereinstimmend die IP 93.189.40.70

[seth]

gudn tach!

oh, pardon, das war ein copy-paste-relikt. wget https://archive.today geht einwandfrei (ohne manipulierten user-agent).

Nö.

ah, interessant, das haengt dann wohl mit den unterschiedlichen ip-zielen abhaengig vom DNS zusammen, von denen du im nachtrag berichtetest. bei mir wird archive.today mit 93.189.40.70 aufgeloest und nicht mit 198.23.187.186 (wie bei dir).

dagegen liefert wget --user-agent='Mozilla' https://archive.md/kmcli einen 200er http-statuscode

Nö.

wget https://archive.md/kmcli
[...]

naja, das ist ja auch ein anderer aufruf. deswegen kann ich dieses "Nö" nicht nachvollziehen.

Ja. Das ist logisch und physikalisch in Russland. Und wenn man der russischen Propaganda folgt, sind wir alle Faschisten, welche dem gottgleichen Wladimir Wladimirowitsch Putin sein Naturrecht auf die Weltherrschaft verweigern. Außerdem muss das Arschiv wohl immer mal bereinigt werden, damit dessen Inhalt zur Prawda (sehr spezielle russisch(e) „Wahrheit“) passt.

ich weiss nicht, was du mir damit sagen moechtest. der beschriebene murks koennte allerdings schon mit russland zusammenhaengen. die maintainer von archive.today sind, wenn ich mich recht entsinne, russen.

gruss

seth

[Raketenwilli]

ah, interessant, das haengt dann wohl mit den unterschiedlichen ip-zielen abhaengig vom DNS zusammen, von denen du im nachtrag berichtetest. bei mir wird archive.today mit 93.189.40.70 aufgeloest und nicht mit 198.23.187.186 (wie bei dir).

Das ist der vierte Grund für doe Offensichtlichkeit:

Es werden die IP-Adressen im DNS offensichtlich häufig geändert. Derlei trifft man an, wenn Webserver erst gespiegelt werden und dann die DNS-Einträge in „hoher“ Frequenz (hier nicht wirklich zutreffend, weil eine Gültigkeit von 300 Sekunden verkündet wird) geändert werden um (vermeintlichen) DDoS-Attacken zu begegnen (Zugriffe auf die alte IP gehen via Routing oder abweisender Firewall ins Leere) - und naja auch bei juristischen Problemen. Offenbar vermuten die Betreiber dann nämlich, dass die vermeintlichen technischen Angreifer die IP nur einmal auflösen und dann dauerhaft (über die TTL hinaus) benutzen…

;; ANSWER SECTION:
archive.today.		300	IN	A	93.189.40.70

Ausschnitt aus der Antwort: Die 300 Sekunden-TTL (Gültigkeit) in der Auskunft der „authorativen“ DNS-Server.

Was die Jungs und Mädels schön zeigen:

Es macht wenig Sinn zu versuchen, einer Überlastung Herr zu werden, in dem man den serverseitig zu betreibenden Aufwand, um eine Webseite auszuliefern, höher und höher schraubt. Die erzeugen offensichtlich die Überlastung am Ende selbst.

Meinung:

Womöglich sollte man die Sharp-Pocket-Computer oder C64-Kisten wieder herstellen und kostengünstig verteilen um das Wissen um die Vorteile minimalistischen Programmierens wieder zu ermöglichen. Denn etwas wie

use bigLibary;         #only  200MB
use anotherBigLibary;  #shiny 1GB
bigLibary.do( anotherBigLibary.do("Huh!", "WhatEver.") );
### Oh! It's so short & i'am ready :-)

### expected Output:
## <p>Huh! WhatEver.</p>

sieht man anno 2023 häufig, ist wieder dem Erwarten nicht effektiv. Es sei denn man will mit der Abwärme des Servers Grönland zum idealen Anbaugebiet von Freiland-Ananas für die Zellulose-Produktion aufwerten.

[seth]

gudn tach!

verstehe ich es richtig, dass du bisher auch keine erklaerung dafuer hast, weshalb es mit firefox/chromium/wget (bei mir) funzt, aber mit curl/python/perl nicht?

gruss

seth

[Raketenwilli]

verstehe ich es richtig, dass du bisher auch keine erklaerung dafuer hast, weshalb es mit firefox/chromium/wget (bei mir) funzt, aber mit curl/python/perl nicht?

Nein. Denn die Erklärung ist einfach:

Die haben Müll „programmiert“(¹).

So wird z.B. (wohl) die geoip-lib(²) benutzt. Denn in der Ausgabe finde ich das hier:

<!-- 95.112.44.16 @ AS6805 -->
<!-- archive.today -->
<!-- sho5 -->
<!-- tno2 -->
<!-- bd50e49d418ed1777b9a410d614440c4 -->
<!-- Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/116.0 -->
<!-- A69 -->

Die kennen also meine IP und das Netz (AS6805). Warum und wie die jetzt darauf kommen, dass aus dem Netz der „Telefonica Germany GmbH & Co. OHG“ böse Zugriffe kommen, kann ich nicht wissen.

¹) „programmiert“ in Anführungsstrichen, weil die offensichtlich einfach Libarys zusammenkopiert haben…

²) Für eine zwischengeschaltete Whois-Abfrage kommt die Antwort zu schnell. Aber es gibt ja das hier: https://www.maxmind.com/en/geoip2-isp-database

[seth]

gudn tach!

verstehe ich es richtig, dass du bisher auch keine erklaerung dafuer hast, weshalb es mit firefox/chromium/wget (bei mir) funzt, aber mit curl/python/perl nicht?

Nein. Denn die Erklärung ist einfach:

Die haben Müll „programmiert“.

naja, soweit war ich ja auch schon vorher. ich meinte es schon etwas differenzierter. :-)

So wird z.B. (wohl) die geoip-lib(²) benutzt. [...]

ich verstehe nicht, weshalb das fuer unterschiedliche ergebnisse je nach browser sorgen soll.

wie gesagt: selbst wenn ich denselben http-request von firefox (wo er mit einem 200er-code quittiert wird) mit curl starte, bekomme ich nach 60s einen 500er wegen timeout.

gruss

seth

[Raketenwilli]

gudn tach!

verstehe ich es richtig, dass du bisher auch keine erklaerung dafuer hast, weshalb es mit firefox/chromium/wget (bei mir) funzt, aber mit curl/python/perl nicht?

Nein. Denn die Erklärung ist einfach:

Die haben Müll „programmiert“.

naja, soweit war ich ja auch schon vorher. ich meinte es schon etwas differenzierter. :-)

So wird z.B. (wohl) die geoip-lib(²) benutzt. [...]

ich verstehe nicht, weshalb das fuer unterschiedliche ergebnisse je nach browser sorgen soll.

Ich zeige nur, was die sonst noch so versuchen …

wie gesagt: selbst wenn ich denselben http-request von firefox (wo er mit einem 200er-code quittiert wird) mit curl starte, bekomme ich nach 60s einen 500er wegen timeout.

Offenbar werfen die dann Deine IP der Firewall zum Fraß vor. Ich mach sowas bei vermuteten Angriffen(¹) auch, bei mir gibts aber vorher einen 403er mit einer kurzen Nachricht.

¹) Gründe für diese Vermutung sind bei mir:

• Zugriffe auf http[s]://$aktuelleIP, also mit falschem Hostname
• Zugriffe auf eine von mir zusammengestellte Liste bekannter Ressourcen - die gar nicht da sind, aber auffällig oft abgerufen werden, um Webserver „auf Schwachstellen abzuklopfen“:

../../../
/a2billing
/actuator/health
/adm
/admin
/administrator.php
/_asterix
authLogin.cgi
/backup
/boaform/admin/formLogin
/cgi-bin/
/composer.php
/config/getuser?index=0
/data.php
/db/
/dbadmin
/db.init.php
/db.php
/db_pma.php
/dmpr/
/drupal.php
/editor.php
/entropysearch.cgi
/goform/formSysCmd
/GponForm/
HelloThinkPHP
/HNAP1/
/horde
/index.php?s=/index/
/ip.php
/login.cgi
/manager
/msd
/muhstik
/mx.php
/myadmin
/MyAdmin
/myadmin2
/mysql
/mysql-admin
/mysql_admin
/mysqladmin
/mysqldump
/mysqldumper
/mysqlmanager
/mysql.php
/noxdir
/.php
/phpadmin
/phpma
/phpmy
/phpmyadmin
/_phpMyAdmin/
/phpMyAdmin/
/phppma
/pma
/pma2
/portal/redlion
/proxyheader.php
/setup.php
/shell.php
/spider.php
/sqlmanager
/sqlweb
/status/
/system.php
/thinkphp
/tomcat.php
/toor.php
/typo3
/uploadify.php
/vhcs/
/vhcs2/
voip.cfg
/vtigercrm
/w00tw00t.at.blackhats.romanian.anti-sec
/webcapture.jpg
/webcm
/webdav
/websql
/wlwmanifest.xml 
/wp-admin
/wp-config
/wp-content
/wp-includes
/wp-login.php
/xampp
/xmlrpc.php

Wer sowas also versucht braucht eine neue IP oder muss erst mal eine Stunde Pause machen…

[Mitleser 2.0]

wie gesagt: selbst wenn ich denselben http-request von firefox (wo er mit einem 200er-code quittiert wird) mit curl starte, bekomme ich nach 60s einen 500er wegen timeout.

Kann ich soweit bestätigen. Zumindest Unterschiedliche Responses. Erklärung habe ich spontan keine. Da scheint eine interessante Heuristik zu arbeiten.

[seth]

gudn tach!

wie gesagt: selbst wenn ich denselben http-request von firefox (wo er mit einem 200er-code quittiert wird) mit curl starte, bekomme ich nach 60s einen 500er wegen timeout.

Kann ich soweit bestätigen. Zumindest Unterschiedliche Responses. Erklärung habe ich spontan keine. Da scheint eine interessante Heuristik zu arbeiten.

ja, das ist auch meine vermutung, nur: heuristik auf wessen seite? hat firefox eine heuristik fuer nicht-standard-konforme responses oder hat archive.today eine heuristik, um curl von firefox zu unterscheiden, obwohl der request eigentlich identisch aufgebaut sein sollte?

gruss

seth

[Mitleser 2.0]

ja, das ist auch meine vermutung, nur: heuristik auf wessen seite? hat firefox eine heuristik fuer nicht-standard-konforme responses oder hat archive.today eine heuristik, um curl von firefox zu unterscheiden, obwohl der request eigentlich identisch aufgebaut sein sollte?

M.E. offensichtlich Letzeres. Interessiert mich aber auch nicht ausreichend, um da tiefer zu graben ;-)

[Raketenwilli]

Moin seth!

Also klar, es liegt am Aǵent-String im Abfrage-Header. Interessanter Weise ist auch das Captcha-Dingens kaputt…

Ursache sind offensichtlich verzweifelt wirkende Versuche, automatisierte Abfragen zu unterbinden.

[seth]

gudn tach!

Also klar, es liegt am Aǵent-String im Abfrage-Header.

nein, ich denke nicht. beim user-agent string wird serverseitig anscheinend nur geprueft, ob er mit "wget" beginnt. daher braucht man nur bei wget einen expliziten (aber nahezu beliebigen) user-agent-string. das von mir beschriebene problem taucht jedoch ohnehin nur bei curl/python/perl auf und liegt fast sicher nicht am user-agent-string.

Interessanter Weise ist auch das Captcha-Dingens kaputt…

welches?

Ursache sind offensichtlich verzweifelt wirkende Versuche, automatisierte Abfragen zu unterbinden.

hmm, offensichtlich finde ich das ueberhaupt nicht.

gruss

seth

[Raketenwilli]

Ursache sind offensichtlich verzweifelt wirkende Versuche, automatisierte Abfragen zu unterbinden.

hmm, offensichtlich finde ich das ueberhaupt nicht.

Lass uns überlegen:

wget und curl sind Werkzeuge, mit denen automatisierte Abfragen gestellt werden können und oft auch werden. Deiner eigenen Aussage nach bekommt man keine Antwort, wenn man diese ohne Angabe eines gewillkürten User-Agent-Headers benutzt. Denn dann weisen diese sich mit eigenem Name und Version aus:

• wget: „User-Agent: Wget/1.21.3“
• curl: „User-Agent: curl/7.88.1“

Gemäß deren Handüchern und nach meiner eignen Erfahrungen, ergo meinem durch eigene Erfahrung gesicherten Wissen machen das PHP, Perl und Python (bzw. deren curl-Libarys) das auch so.

Damit ist - jedenfalls für mich - der Versuch der Abweisung automatisierter Zugriffe „höchst offensichtlich“.

Interessanter Weise ist auch das Captcha-Dingens kaputt…

welches?

Guggst Du Pic:

Wenn sodann in der Kombination aus Auslesen des User-Agenten aus dem Request-Header und Captcha etwas derart kaputtes herauskommt, ist der Versuch, automatisierte Abfragen zu unterbinden, nicht nur „offensichtlich“, sondern auch „verzweifelt“ - und im Übrigen als gescheitert anzusehen.

Dann wäre da noch das hier:

Auf der Webseite erscheint (im nicht gezeigten Bereich) folgender Text:

„Completing the CAPTCHA proves you are a human and gives you temporary access to the web property.“

Der Webseitenbetreiber veröffentlicht also selbst, dass er alles, was nach seiner Ansicht und gemäß seiner, durch technische Vermutungen eines Automaten generierten Ansicht kein „Menschen“ ist, auschließen will.

---

Bevor gefragt wird:

Ich habe nur zwei Add-Ons (Privacy Badger und uBlock) und sperre zusätzlich bekannte AddServer per DNS.

[seth]

gud tach!

ach, das captcha kommt bei dir schon beim aufruf von archive.today? interessant. ich hatte das noch nie, sondern nur beim speichern von neuen eintraegen dort. evtl. kommen aus deiner ip-range besonders viele requests.

jedenfalls wird das mein problem nicht sein, da mir kein captcha vorgesetzt wird. aber trotzdem gut zu wissen, dass dies offenbar manchmal der fall ist.

gruss seth