I tried a little Mac program I found on the net that finds link errors. I've sorted the output by source file and by error type. I've used Arthur's new pages@genealogy.net e-mail address to upload these two files to http://www.genealogy.com/gene/tmp/up/pages in bberrors_by_source.html and bberrors_by_type.html. Many of the errors are extremely minor ones where the referring page uses a link like http://www.that.site/that_directory and the other server returns a redirection to http://www.that.site/that_directory/ (note the trailing slash). But still there are some errors that aren't being caught by Arthur's link checker. I didn't go the other way around to see if the Mac program is missing some that Arthur catches. =Jim Eggert EggertJ@LL.mit.edu
On Wed, 23 Jul 1997, Jim Eggert wrote:
I tried a little Mac program I found on the net that finds link
Ganz schoen gut. Wie lange laeuft das?
errors. I've sorted the output by source file and by error type.
letzteres gefaellt mir besser. Wenn nur noch temporarily moved kommt, kann man meistens aufhoeren, dann fehlt meist nur der / am Ende.
I've used Arthur's new pages@genealogy.net e-mail address to upload these two files to http://www.genealogy.com/gene/tmp/up/pages in bberrors_by_source.html and bberrors_by_type.html.
Leider hat das nicht so geklappt, wie ich mir das gedacht hatte. Ich bin wohl faelschlicherweise davon ausgegangen, dass ich mich auf MIME Nachrichten verlassen kann, die den Content-Type brav in den Headerzeilen beschreiben. Immerhin ist es in AZ angekommen, wenn auch nur als ein grosses File "More", statt als 2 Files mit den von Dir gewaehlten Titeln. Wundersamerweise erkennt der MS Internet Explorer, dass es sich um HTML handelt (ob das an <html> in der 2. Zeile liegt?)
Many of the errors are extremely minor ones where the referring page uses a link like http://www.that.site/that_directory and the other server returns a redirection to http://www.that.site/that_directory/ (note the trailing slash).
Das ist allerdings etwas stoerend, aus diesem Grund lasse ich die 301/302 Meldungen im Report weg. Interessant sind diese Meldungen nur wenn sie wirklich woandershin zeigen, das muesste man mit einem Stringvergleich herausfinden koennen. Der User draussen merkt das nicht, ausser wenn er eine extrem langsame Leitung hat, bei der sich der zusaetzliche Zugriff stoerend bemerkbar macht.
But still there are some errors that aren't being caught by Arthur's link checker. I didn't go the other way around to see if the Mac program is missing some that Arthur catches.
Ich fange auch die, die eigentlich auskommentiert sind ;-) Wohl mehr ein bug als ein feature. Die dead links, die nicht in meinem aber in Deinem Report stehen, haben bei mir alle die Kennung 603 (timed out), so dass ich nicht bestimmen konnte, ob es eine Seite nicht vielleicht doch gibt. Der Timeout ist bei mir relativ kurz (30sec) gesetzt, damit das Programm auch irgendwann einmal fertig wird. Zur Sicherheit lasse ich es aber 2x laufen und probiere im zweiten Versuch die, zu denen das Programm im ersten Versuch nichts sagen konnte. Wie gesagt, ich will das Programm ueberarbeiten, so dass nur noch die neuen Files gecheckt werden (und die externen Links in groesserem Abstand). Dann laesst es sich auch besser testen. Arthur.Teschler@uni-giessen.de
Arthur schrieb:
I tried a little Mac program I found on the net that finds link
Ganz schoen gut. Wie lange laeuft das?
Ich weiss nicht, vielleicht eine Stunde.
I've used Arthur's new pages@genealogy.net e-mail address to upload these two files to http://www.genealogy.com/gene/tmp/up/pages in bberrors_by_source.html and bberrors_by_type.html.
Leider hat das nicht so geklappt, wie ich mir das gedacht hatte.
Ok, dann hab ich die zwei Files ge-ftp'd. Sie sind in <http://www.genealogy.com/gene/tmp/up/pages/> zu finden.
Many of the errors are extremely minor ones where the referring page uses a link like http://www.that.site/that_directory and the other server returns a redirection to http://www.that.site/that_directory/ (note the trailing slash).
Das ist allerdings etwas stoerend, aus diesem Grund lasse ich die 301/302 Meldungen im Report weg.
Stoerend vielleicht, aber einfach weglassen soll man in allen Faellen nicht.
Interessant sind diese Meldungen nur wenn sie wirklich woandershin zeigen, das muesste man mit einem Stringvergleich herausfinden koennen.
Habe ich gemacht. In einer zweiten Version, bberrors_by_type2.html, sind diejenigen, die nicht nur blah vs. blah/ sind, fett gedruckt.
Der User draussen merkt das nicht, ausser wenn er eine extrem langsame Leitung hat, bei der sich der zusaetzliche Zugriff stoerend bemerkbar macht.
Redirects auf Files wie /nim/nosuchfile.html oder http://www1.netcom.com/personal/pages/error.html?uid=gvoss sind Fehlermeldungen. Der User wird das schon merken. Ich glaube, wir sollten Redirects dann vermeiden, wenn sie nutzlos sind. Viele Links ohne "/" am Ende, die einen Redirect erzeugen, sollen wir korrigieren.
Die dead links, die nicht in meinem aber in Deinem Report stehen, haben bei mir alle die Kennung 603 (timed out), so dass ich nicht bestimmen konnte, ob es eine Seite nicht vielleicht doch gibt. Der Timeout ist bei mir relativ kurz (30sec) gesetzt, damit das Programm auch irgendwann einmal fertig wird.
Ich habe fuer das Mac Programm ("Big Brother") den Timeout auf 180 Sekunden gesetzt. Dagegen kann das Ding 30-40 Links gleichzeitig testen. Trotz des laengeren Timeouts musste ich sowieso heut morgen die toten Links nochmals per Hand durchgehen, und habe etliche doch lebendig gefunden. Diese habe ich schon von den Files geloescht. =Jim Eggert EggertJ@LL.mit.edu
On Wed, 23 Jul 1997, Jim Eggert wrote:
Ich weiss nicht, vielleicht eine Stunde.
Nicht schlecht.
Stoerend vielleicht, aber einfach weglassen soll man in allen Faellen nicht.
Richtig. Allerdings ist der Report, so wie er jetzt ist, so lang, dass ihn kaum einer liest. Das ist ja schon bei dem aktuellen Report so. Einige Fehler werden schon seit Wochen gemeldet und niemand kuemmert sich.
Interessant sind diese Meldungen nur wenn sie wirklich woandershin zeigen, das muesste man mit einem Stringvergleich herausfinden koennen.
Habe ich gemacht. In einer zweiten Version, bberrors_by_type2.html, sind diejenigen, die nicht nur blah vs. blah/ sind, fett gedruckt.
Schoen!
Der User draussen merkt das nicht, ausser wenn er eine extrem langsame Leitung hat, bei der sich der zusaetzliche Zugriff stoerend bemerkbar macht.
Redirects auf Files wie /nim/nosuchfile.html oder http://www1.netcom.com/personal/pages/error.html?uid=gvoss sind Fehlermeldungen. Der User wird das schon merken.
Beide muessten eigentlich 404 Meldungen sein. Ein Fehler des jeweiligen Webadmins.
Ich glaube, wir sollten Redirects dann vermeiden, wenn sie nutzlos sind. Viele Links ohne "/" am Ende, die einen Redirect erzeugen, sollen wir korrigieren.
Hmm, das hoert sich nach Arbeit an.
Ich habe fuer das Mac Programm ("Big Brother") den Timeout auf 180 Sekunden gesetzt. Dagegen kann das Ding 30-40 Links gleichzeitig testen.
Parallel ist natuerlich ein immenser Vorteil. Ich muss das nicht unbedingt bei mir machen. Wenn es offensichtlich leistungsfaehigere Tools gibt, habe ich nichts dagegen, sie zu nutzen. Kannst Du das regelmaessig laufen lassen? Arthur.Teschler@uni-giessen.de
Arthur schrieb:
Kannst Du das [Big Brother link checker] regelmaessig laufen lassen?
Im Grunde genommen schon, aber 1. Die Sortierungen und Fettdruck der wichtigen gemoved Links habe ich selber gemacht, also nicht automatisch. 2. Solche Link-Tests sollten lieber lokal gemacht werden. 3. Big Brother muss jedesmal alle Links pruefen, und nicht nur die von neuen Seiten. (Ob das ueberhaupt sinnvoll ist, weiss ich nicht!) =Jim Eggert EggertJ@LL.mit.edu
On Wed, 23 Jul 1997, Jim Eggert wrote:
Kannst Du das [Big Brother link checker] regelmaessig laufen lassen?
Im Grunde genommen schon, aber
1. Die Sortierungen und Fettdruck der wichtigen gemoved Links habe ich selber gemacht, also nicht automatisch.
Koennte man aber automatisieren, oder?
2. Solche Link-Tests sollten lieber lokal gemacht werden.
Das stimmt allerdings. Wobei die lokalen Links nicht das grosse Problem sind, sondern sie externen. Und da hast Du anscheinend die bessere Anbindung.
3. Big Brother muss jedesmal alle Links pruefen, und nicht nur die von neuen Seiten. (Ob das ueberhaupt sinnvoll ist, weiss ich nicht!)
Ich wuerde die (alten) externen Links weiterhin pruefen, aber nicht so oft. Alle zwei,drei Wochen sollte eigentlich reichen, so oft verschwinden die Seiten ja nun auch wieder nicht. Wir muessen ja nicht paepstlicher sein als der Papst ;-) Ich mach mir nochmal ein paar Gedanken. Arthur.Teschler@uni-giessen.de PS: Heute frueh weg. Muss noch meine neue Wohnung ausmessen. Vielleicht koennen wir die Moebel gar nicht aufstellen ?! PSS: www.teleauskunft1188.de ist zwar langsam, aber beeindruckend aktuell. Mein Kollege hat sein Telefon am Montag in Betrieb genommen und steht bereits drin. Die Telekomiker sitzen eben an der Quelle.
Two questions and a pointer to a couple of typos: 1. What do the red balls mean on the web page <http://www.genealogy.com/gene/reg/ger1871.htm> ? They aren't explained anywhere. 2. Why don't we have a page for Oldenburg? (Fred?) 3. And there are a few simple typos on the web page <http://www.genealogy.com/gene/reg/POS/posen.html> where it says: Germany reoccupied Posen province 1939-1945 and renamed in Warthegau. t and Forschunfsauftr"age werden nicht "ubernommen, sondern nur Aufk"unfte ... g s =Jim Eggert EggertJ@LL.mit.edu
Two questions and a pointer to a couple of typos:
1. What do the red balls mean on the web page <http://www.genealogy.com/gene/reg/ger1871.htm> ? They aren't explained anywhere.
I think Arthur put them in as a signal that we still need to work on them.
2. Why don't we have a page for Oldenburg? (Fred?)
Time my friend, time is the culprit. so much to do, so little time. Don't know who worked on Posen, probably Rick. Fred Fred Rump http://www.k2nesoft.com/~fred 26 Warren St Beverly, NJ 08010 fred@compu.com or 609-386-6846 fred@k2nesoft.com
Redirects auf Files wie /nim/nosuchfile.html oder http://www1.netcom.com/personal/pages/error.html?uid=gvoss sind Fehlermeldungen. Der User wird das schon merken.
Ich glaube, wir sollten Redirects dann vermeiden, wenn sie nutzlos sind. Viele Links ohne "/" am Ende, die einen Redirect erzeugen, sollen wir korrigieren.
I get these as RED errors too in my list from WEBanalyzer. Fred Fred Rump http://www.k2nesoft.com/~fred 26 Warren St Beverly, NJ 08010 fred@compu.com or 609-386-6846 fred@k2nesoft.com
participants (3)
-
Arthur Teschler
-
Jim Eggert
-
W. Fred Rump