info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Webserver-Umzug mit Umleitung (was: Urheberrecht und Usenet)
0 views
Skip to first unread message
Helmut Richter
Dec 22, 2022, 5:19:34 AM12/22/22
to
[ Followup-To: de.comm.infosystems.www.authoring.misc ]
On Wed, 21 Dec 2022, Thomas Hochstein wrote:
> Marco Moock schrieb:
>
> > Und die meisten URLs sind nach 20 Jahren nicht mehr gültig.
>
> Viele halten nicht einmal 10 oder 5 Jahre.
Für die von mir verwalteten Webauftritte möchte ich möglichst lange
Gültigkeit von URLs erreichen, mindestens die Seiten nach 2012 sollen noch
eine Weile auffindbar sein. Das ist ziemlicher Aufwand. Es ist leider
technisch nicht immer ganz einfach, für die längere Gültigkeit des alten
URL zu sorgen, wenn eine Seite umzieht, also einen neuen URL bekommt.
Am leichtesten ist es, wenn alles am selben Server passiert oder an Servern,
deren Verwalter dauerhaft kooperieren. Dann benutzt man den alten URL *nie*
für eine andere Webseite als bisher und leitet per 301 um. Die alten Benutzer
der Seite, die sich den alten URL gemerkt haben, werden das oft nicht
bemerken und den alten URL möglicherweise jahrelang weiter benutzen.
Will man das nicht oder hat man wegen Providerwechsels nur beschränkt lange
Einfluss auf die Nutzung des alten URLs, kenne ich keine einfache Lösung. Was
nicht geht:
– Umleitung per 301: Die menschlichen Benutzer merkens nicht und stehen bei
Aufgabe des alten URL vor dem Nichts.
– Umleitung per 307: gleiches Problem, zusätzlich lernen die Suchmaschinen
den neuen URL nicht.
– Umleitung per 301 auf neuen Server, aber nicht an den künftigen URL: Die
menschlichen Benutzer werden informiert, aber die Suchmaschinen lernen
einen neuen falschen URL, so dass deren Kunden mit unnötigen Hinweisen
belästigt werden.
Was ich probiert habe und geht, ohne dass Benutzer des neuen URL mit für
sie überflüssigen Hinweisen belästigt werden:
– Umleitung per 301 an den neuen URL mit Angabe eines Fragmentbezeichners
(im Beispiel „badURL“), der auf einen Hinweis zeigt, der per CSS nur
dann angezeigt wird, wenn er benutzt wird:
Beispiel: lochhausener-singkreis.userweb.mwn.de (ausprobieren)
Was ich noch ausprobieren möchte:
– Umleitung per 301 an den neuen URL mit Angabe des vom Nutzer
verwendeten URL im Fragmentbezweichner: Man kann dann den Hinweis an den
Benutzer flexibler gestalten und die Fälle „Seite liegt serverrelativ am
gleichen Ort“, „Seite ist noch (=wieder) da, hat aber geänderten
dauerhaften Pfad“, „Seite ist noch da, aber auf provisorischen Pfad“ nach
einheitlichen Algorithmen abhandeln, die auf leicht änderbare Daten
zugreifen.
Alles mit Trickserei-Aufwand verbunden. Weiß jemand eine einfachere Lösung?
--
Helmut Richter
On Wed, 21 Dec 2022, Thomas Hochstein wrote:
> Marco Moock schrieb:
>
> > Und die meisten URLs sind nach 20 Jahren nicht mehr gültig.
>
> Viele halten nicht einmal 10 oder 5 Jahre.
Für die von mir verwalteten Webauftritte möchte ich möglichst lange
Gültigkeit von URLs erreichen, mindestens die Seiten nach 2012 sollen noch
eine Weile auffindbar sein. Das ist ziemlicher Aufwand. Es ist leider
technisch nicht immer ganz einfach, für die längere Gültigkeit des alten
URL zu sorgen, wenn eine Seite umzieht, also einen neuen URL bekommt.
Am leichtesten ist es, wenn alles am selben Server passiert oder an Servern,
deren Verwalter dauerhaft kooperieren. Dann benutzt man den alten URL *nie*
für eine andere Webseite als bisher und leitet per 301 um. Die alten Benutzer
der Seite, die sich den alten URL gemerkt haben, werden das oft nicht
bemerken und den alten URL möglicherweise jahrelang weiter benutzen.
Will man das nicht oder hat man wegen Providerwechsels nur beschränkt lange
Einfluss auf die Nutzung des alten URLs, kenne ich keine einfache Lösung. Was
nicht geht:
– Umleitung per 301: Die menschlichen Benutzer merkens nicht und stehen bei
Aufgabe des alten URL vor dem Nichts.
– Umleitung per 307: gleiches Problem, zusätzlich lernen die Suchmaschinen
den neuen URL nicht.
– Umleitung per 301 auf neuen Server, aber nicht an den künftigen URL: Die
menschlichen Benutzer werden informiert, aber die Suchmaschinen lernen
einen neuen falschen URL, so dass deren Kunden mit unnötigen Hinweisen
belästigt werden.
Was ich probiert habe und geht, ohne dass Benutzer des neuen URL mit für
sie überflüssigen Hinweisen belästigt werden:
– Umleitung per 301 an den neuen URL mit Angabe eines Fragmentbezeichners
(im Beispiel „badURL“), der auf einen Hinweis zeigt, der per CSS nur
dann angezeigt wird, wenn er benutzt wird:
Beispiel: lochhausener-singkreis.userweb.mwn.de (ausprobieren)
Was ich noch ausprobieren möchte:
– Umleitung per 301 an den neuen URL mit Angabe des vom Nutzer
verwendeten URL im Fragmentbezweichner: Man kann dann den Hinweis an den
Benutzer flexibler gestalten und die Fälle „Seite liegt serverrelativ am
gleichen Ort“, „Seite ist noch (=wieder) da, hat aber geänderten
dauerhaften Pfad“, „Seite ist noch da, aber auf provisorischen Pfad“ nach
einheitlichen Algorithmen abhandeln, die auf leicht änderbare Daten
zugreifen.
Alles mit Trickserei-Aufwand verbunden. Weiß jemand eine einfachere Lösung?
--
Helmut Richter
Arno Welzel
Dec 22, 2022, 7:53:45 AM12/22/22
to
Helmut Richter, 2022-12-22 11:19:
> [ Followup-To: de.comm.infosystems.www.authoring.misc ]
>
> On Wed, 21 Dec 2022, Thomas Hochstein wrote:
>
>> Marco Moock schrieb:
>>
>>> Und die meisten URLs sind nach 20 Jahren nicht mehr gültig.
>>
>> Viele halten nicht einmal 10 oder 5 Jahre.
>
> Für die von mir verwalteten Webauftritte möchte ich möglichst lange
> Gültigkeit von URLs erreichen, mindestens die Seiten nach 2012 sollen noch
> eine Weile auffindbar sein. Das ist ziemlicher Aufwand. Es ist leider
> technisch nicht immer ganz einfach, für die längere Gültigkeit des alten
> URL zu sorgen, wenn eine Seite umzieht, also einen neuen URL bekommt.
Doch, das ist sehr einfach. Man muss nur eine passender Weiterleitung
anlegen, z.B. per .htaccess und Redirect oder RewriteRule. Erst recht,
wenn Du die Webauftritte selber verwaltest.
[...]
"Location:"-Header. 301 ist der *Status*, der dazu angegeben wird.
Und wieso sollten Besucher da vor dem "Nichts" stehen?
Hier eine meiner alten URLs, die so umleiten (eine von sehr vielen):
<https://arnowelzel.de/wiki/de/fahrrad/>
Der Server hat halt Weiterleitungsregeln, die solche URLs mit einem
passenden "Location:"-Header und Status-Code 301 für "Moved Permanently"
antworten:
HTTP/1.1 301 Moved Permanently
Location: https://arnowelzel.de/kategorie/fahrrad
> Alles mit Trickserei-Aufwand verbunden. Weiß jemand eine einfachere Lösung?
Siehe oben. Ich verstehe nicht, was dein Problem ist.
--
Arno Welzel
https://arnowelzel.de
> [ Followup-To: de.comm.infosystems.www.authoring.misc ]
>
> On Wed, 21 Dec 2022, Thomas Hochstein wrote:
>
>> Marco Moock schrieb:
>>
>>> Und die meisten URLs sind nach 20 Jahren nicht mehr gültig.
>>
>> Viele halten nicht einmal 10 oder 5 Jahre.
>
> Für die von mir verwalteten Webauftritte möchte ich möglichst lange
> Gültigkeit von URLs erreichen, mindestens die Seiten nach 2012 sollen noch
> eine Weile auffindbar sein. Das ist ziemlicher Aufwand. Es ist leider
> technisch nicht immer ganz einfach, für die längere Gültigkeit des alten
> URL zu sorgen, wenn eine Seite umzieht, also einen neuen URL bekommt.
anlegen, z.B. per .htaccess und Redirect oder RewriteRule. Erst recht,
wenn Du die Webauftritte selber verwaltest.
[...]
> Will man das nicht oder hat man wegen Providerwechsels nur beschränkt lange
> Einfluss auf die Nutzung des alten URLs, kenne ich keine einfache Lösung. Was
> nicht geht:
>
> – Umleitung per 301: Die menschlichen Benutzer merkens nicht und stehen bei
> Aufgabe des alten URL vor dem Nichts.
Man leitet nicht "per 301" um! Die Umleitung erfolgt mit
> Einfluss auf die Nutzung des alten URLs, kenne ich keine einfache Lösung. Was
> nicht geht:
>
> – Umleitung per 301: Die menschlichen Benutzer merkens nicht und stehen bei
> Aufgabe des alten URL vor dem Nichts.
"Location:"-Header. 301 ist der *Status*, der dazu angegeben wird.
Und wieso sollten Besucher da vor dem "Nichts" stehen?
Hier eine meiner alten URLs, die so umleiten (eine von sehr vielen):
<https://arnowelzel.de/wiki/de/fahrrad/>
Der Server hat halt Weiterleitungsregeln, die solche URLs mit einem
passenden "Location:"-Header und Status-Code 301 für "Moved Permanently"
antworten:
HTTP/1.1 301 Moved Permanently
Location: https://arnowelzel.de/kategorie/fahrrad
> Alles mit Trickserei-Aufwand verbunden. Weiß jemand eine einfachere Lösung?
--
Arno Welzel
https://arnowelzel.de
Helmut Richter
Dec 22, 2022, 11:34:40 AM12/22/22
to
On Thu, 22 Dec 2022, Arno Welzel wrote:
> Date: Thu, 22 Dec 2022 13:53:43
> From: Arno Welzel <use...@arnowelzel.de>
> Newsgroups: de.comm.infosystems.www.authoring.misc
> Subject: Re: Webserver-Umzug mit Umleitung (was: Urheberrecht und Usenet)
Ich bitte „Umleitung per 301“ zu ersetzen durch das viel verständlichere
„Umleitung durch Rückgabe eines HTTP-Status 301 mit zusätzlichem
Location-Header, der den Ziel-URL angibt“. Dankenswerterweise hast du mir
ja weiter unten erläutert, wie man das richtig macht.
> Hier eine meiner alten URLs, die so umleiten (eine von sehr vielen):
>
> <https://arnowelzel.de/wiki/de/fahrrad/>
--2022-12-22 16:00:46-- https://arnowelzel.de/wiki/de/fahrrad/
--2022-12-22 16:00:46-- https://arnowelzel.de/kategorie/fahrrad
HTTP/1.1 301 Moved Permanently
Location: https://arnowelzel.de/thema//fahrrad
--2022-12-22 16:00:46-- https://arnowelzel.de/thema//fahrrad
HTTP/1.1 301 Moved Permanently
Location: https://arnowelzel.de/thema/fahrrad
--2022-12-22 16:00:46-- https://arnowelzel.de/thema/fahrrad
HTTP/1.1 200 OK
Ja, das ist der triviale Fall, dass der ursprüngliche URL nach wie vor bei
einem Server unter der eigenen Regie landet. Bei Aufgabe der bisherigen
Domain wegen Providerwechsel ist das nicht der Fall. Im nicht zitierten Teil
meines Beitrags stand das im Absatz „Am leichtesten ...“.
[ Zitatreihenfolge vertauscht ]
> Und wieso sollten Besucher da vor dem "Nichts" stehen?
Alter Zustand: nur der bisherige Server bedient den alten URL.
Zwischenzustand: Die Webseite ist auf einen anderen Server in einer
anderen Domain umgezogen, und der bisherige Server leitet per 301 ... äääh
sendet den HTTP-Status 301 mit zusätzlichem Location-Header, der den neuen
URL auf dem neuen Server angibt. In diesem Zustand geschieht folgendes:
– Suchmaschinen lernen dazu, meist langsam (weil sie scheints bei „moved
permanently“ die behauptete Dauerhaftigkeit nicht gleich glauben), aber
doch nach und nach.
– Menschliche Benutzer, die den bisherigen URL kennen (aus früheren
Zugriffen oder aus veralteten Links von dritter Seite), können ihn weiter
verwenden und viele werden das tun, weil sie nicht den vom Browser
angezeigten mit dem tatsächlich benutzten URL vergleichen.
Neuer Zustand: der alte Server ist abgeschaltet
– Suchmaschinen liefern einwandfreie Ergebnisse, wenn der Zwischenzustand
lang genug zum Lernen war.
– Die obengenannten menschlichen Benutzer bekommen die Seite nicht mehr – am
Tag vorher gings noch und es gab keine Vorwarnung.
So unrealistisch ist das nicht. Ob es bei deinem Server realistisch wäre,
kannst du feststellen, indem du im Access-Log nachschaust, wie oft deine
alten URLs noch verwendet werden.
Das Problem ist jetzt: wie kann ich die Benutzer der alten URLs vor der
Abschaltung warnen, ohne dass Suchmaschinen verwirrt werden und ohne dass
Benutzer der neuen URLs unnötige Warnhinweise bekommen?
Zeithorizont bei mir (als Beispiel):
Seit Sommer 2021 gibt es die neuen Server, einer mit einer neuen und einer
mit einer umgezogenen Domain. Die Server, die bisher die Webdaten hielten,
sind weitgehend freigeräumt. Das möchte ich jetzt abschließen. Bis Mitte 2023
sollen sie aber in Betrieb bleiben, um ihre Zertifikate für die alten URLs
vorzulegen und um Weiterleitungen durchzuführen. Danach soll nur noch
weiterbestehen, was billig zu haben ist. Damit habe ich etwa 18 Monate
Übergangsfrist, wo alte wie neue URLs funktionieren und mindestens 6 Monate,
wo menschliche Benutzer der alten URLs gewarnt werden, dass diese auslaufen.
--
Helmut Richter
> Date: Thu, 22 Dec 2022 13:53:43
> From: Arno Welzel <use...@arnowelzel.de>
> Newsgroups: de.comm.infosystems.www.authoring.misc
> Subject: Re: Webserver-Umzug mit Umleitung (was: Urheberrecht und Usenet)
>
> Helmut Richter, 2022-12-22 11:19:
>
> > [ Followup-To: de.comm.infosystems.www.authoring.misc ]
> >
> > On Wed, 21 Dec 2022, Thomas Hochstein wrote:
> >
> >> Marco Moock schrieb:
> >>
> >>> Und die meisten URLs sind nach 20 Jahren nicht mehr gültig.
> >>
> >> Viele halten nicht einmal 10 oder 5 Jahre.
> >
> > Für die von mir verwalteten Webauftritte möchte ich möglichst lange
> > Gültigkeit von URLs erreichen, mindestens die Seiten nach 2012 sollen noch
> > eine Weile auffindbar sein. Das ist ziemlicher Aufwand. Es ist leider
> > technisch nicht immer ganz einfach, für die längere Gültigkeit des alten
> > URL zu sorgen, wenn eine Seite umzieht, also einen neuen URL bekommt.
>
> Doch, das ist sehr einfach. Man muss nur eine passender Weiterleitung
> anlegen, z.B. per .htaccess und Redirect oder RewriteRule. Erst recht,
> wenn Du die Webauftritte selber verwaltest.
>
> [...]
> > Will man das nicht oder hat man wegen Providerwechsels nur beschränkt lange
> > Einfluss auf die Nutzung des alten URLs, kenne ich keine einfache Lösung. Was
> > nicht geht:
> >
> > – Umleitung per 301: Die menschlichen Benutzer merkens nicht und stehen bei
> > Aufgabe des alten URL vor dem Nichts.
>
> Man leitet nicht "per 301" um! Die Umleitung erfolgt mit
> "Location:"-Header. 301 ist der *Status*, der dazu angegeben wird.
Oh, Entschuldigung. Ich konnte nicht ahnen, dass man das nicht versteht.
> Helmut Richter, 2022-12-22 11:19:
>
> > [ Followup-To: de.comm.infosystems.www.authoring.misc ]
> >
> > On Wed, 21 Dec 2022, Thomas Hochstein wrote:
> >
> >> Marco Moock schrieb:
> >>
> >>> Und die meisten URLs sind nach 20 Jahren nicht mehr gültig.
> >>
> >> Viele halten nicht einmal 10 oder 5 Jahre.
> >
> > Für die von mir verwalteten Webauftritte möchte ich möglichst lange
> > Gültigkeit von URLs erreichen, mindestens die Seiten nach 2012 sollen noch
> > eine Weile auffindbar sein. Das ist ziemlicher Aufwand. Es ist leider
> > technisch nicht immer ganz einfach, für die längere Gültigkeit des alten
> > URL zu sorgen, wenn eine Seite umzieht, also einen neuen URL bekommt.
>
> Doch, das ist sehr einfach. Man muss nur eine passender Weiterleitung
> anlegen, z.B. per .htaccess und Redirect oder RewriteRule. Erst recht,
> wenn Du die Webauftritte selber verwaltest.
>
> [...]
> > Will man das nicht oder hat man wegen Providerwechsels nur beschränkt lange
> > Einfluss auf die Nutzung des alten URLs, kenne ich keine einfache Lösung. Was
> > nicht geht:
> >
> > – Umleitung per 301: Die menschlichen Benutzer merkens nicht und stehen bei
> > Aufgabe des alten URL vor dem Nichts.
>
> Man leitet nicht "per 301" um! Die Umleitung erfolgt mit
> "Location:"-Header. 301 ist der *Status*, der dazu angegeben wird.
Ich bitte „Umleitung per 301“ zu ersetzen durch das viel verständlichere
„Umleitung durch Rückgabe eines HTTP-Status 301 mit zusätzlichem
Location-Header, der den Ziel-URL angibt“. Dankenswerterweise hast du mir
ja weiter unten erläutert, wie man das richtig macht.
> Hier eine meiner alten URLs, die so umleiten (eine von sehr vielen):
>
> <https://arnowelzel.de/wiki/de/fahrrad/>
--2022-12-22 16:00:46-- https://arnowelzel.de/kategorie/fahrrad
HTTP/1.1 301 Moved Permanently
Location: https://arnowelzel.de/thema//fahrrad
--2022-12-22 16:00:46-- https://arnowelzel.de/thema//fahrrad
HTTP/1.1 301 Moved Permanently
Location: https://arnowelzel.de/thema/fahrrad
--2022-12-22 16:00:46-- https://arnowelzel.de/thema/fahrrad
HTTP/1.1 200 OK
Ja, das ist der triviale Fall, dass der ursprüngliche URL nach wie vor bei
einem Server unter der eigenen Regie landet. Bei Aufgabe der bisherigen
Domain wegen Providerwechsel ist das nicht der Fall. Im nicht zitierten Teil
meines Beitrags stand das im Absatz „Am leichtesten ...“.
[ Zitatreihenfolge vertauscht ]
> Und wieso sollten Besucher da vor dem "Nichts" stehen?
Zwischenzustand: Die Webseite ist auf einen anderen Server in einer
anderen Domain umgezogen, und der bisherige Server leitet per 301 ... äääh
sendet den HTTP-Status 301 mit zusätzlichem Location-Header, der den neuen
URL auf dem neuen Server angibt. In diesem Zustand geschieht folgendes:
– Suchmaschinen lernen dazu, meist langsam (weil sie scheints bei „moved
permanently“ die behauptete Dauerhaftigkeit nicht gleich glauben), aber
doch nach und nach.
– Menschliche Benutzer, die den bisherigen URL kennen (aus früheren
Zugriffen oder aus veralteten Links von dritter Seite), können ihn weiter
verwenden und viele werden das tun, weil sie nicht den vom Browser
angezeigten mit dem tatsächlich benutzten URL vergleichen.
Neuer Zustand: der alte Server ist abgeschaltet
– Suchmaschinen liefern einwandfreie Ergebnisse, wenn der Zwischenzustand
lang genug zum Lernen war.
– Die obengenannten menschlichen Benutzer bekommen die Seite nicht mehr – am
Tag vorher gings noch und es gab keine Vorwarnung.
So unrealistisch ist das nicht. Ob es bei deinem Server realistisch wäre,
kannst du feststellen, indem du im Access-Log nachschaust, wie oft deine
alten URLs noch verwendet werden.
Das Problem ist jetzt: wie kann ich die Benutzer der alten URLs vor der
Abschaltung warnen, ohne dass Suchmaschinen verwirrt werden und ohne dass
Benutzer der neuen URLs unnötige Warnhinweise bekommen?
Zeithorizont bei mir (als Beispiel):
Seit Sommer 2021 gibt es die neuen Server, einer mit einer neuen und einer
mit einer umgezogenen Domain. Die Server, die bisher die Webdaten hielten,
sind weitgehend freigeräumt. Das möchte ich jetzt abschließen. Bis Mitte 2023
sollen sie aber in Betrieb bleiben, um ihre Zertifikate für die alten URLs
vorzulegen und um Weiterleitungen durchzuführen. Danach soll nur noch
weiterbestehen, was billig zu haben ist. Damit habe ich etwa 18 Monate
Übergangsfrist, wo alte wie neue URLs funktionieren und mindestens 6 Monate,
wo menschliche Benutzer der alten URLs gewarnt werden, dass diese auslaufen.
--
Helmut Richter
Ignatios Souvatzis
Dec 22, 2022, 3:40:08 PM12/22/22
to
Helmut Richter wrote:
> Für die von mir verwalteten Webauftritte möchte ich möglichst lange
> Gültigkeit von URLs erreichen, mindestens die Seiten nach 2012 sollen noch
> eine Weile auffindbar sein.
Naja. Für einzelne Dokumente ist das einfach: füge in kleiner
> Für die von mir verwalteten Webauftritte möchte ich möglichst lange
> Gültigkeit von URLs erreichen, mindestens die Seiten nach 2012 sollen noch
> eine Weile auffindbar sein.
Schrift irgendwo in der Ecke eine lange gewuerfelte ID ein (hex
oder base64), die von Suchmaschinen indizierbar ist; dann kannst
du deine Leserinnen auch 30 Jahre später danach suchen lassen,
sofern dein Zieldokument noch irgendwo vorhanden und suchbar ist.
(Suchen und URL aufrufen ist bei den meisten Browsern heutzutage
ja eh ununterscheidbar).
Hab' vergessen, wer das vor gefühlt 20 Jahren mal vorgeschlagen hat.
Als Korrolar daraus: bau dir daraus deine Links zusammen, quasi
direktaufruf der Suche. Z.B.
https://search.yahoo.com/search?p=deincode
Du musst halt ab und zu die links passend abaendern, wenn
Suchmaschinenbetreiber umbauen.
Die Links innerhalb einer zusammengehörigen Gruppe von Dokumenten
kannst du ja relativ setzen, das deckt die einfachen Fälle ab.
-is
Arno Welzel
Dec 22, 2022, 3:53:38 PM12/22/22
to
Helmut Richter, 2022-12-22 17:34:
Nein, darum geht es nicht.
Die Umleitung erfolgt durch Header. Der Status ist dabei völlig egal und
gibt nur an, *warum* umgeleitet wurde - und das kann neben 301 eben auch
302, 303, 307 oder 201 sein.
Siehe auch:
<https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Location>
> Ich bitte „Umleitung per 301“ zu ersetzen durch das viel verständlichere
> „Umleitung durch Rückgabe eines HTTP-Status 301 mit zusätzlichem
> Location-Header, der den Ziel-URL angibt“. Dankenswerterweise hast du mir
> ja weiter unten erläutert, wie man das richtig macht.
Deine Polemik ist hier fehl am Platz. Wenn man technische Probleme
erörtert, sollte man sich halt genau ausdrücken, um Mißverständnisse zu
vermeiden. Auch vermeidet man so Rückfragen, was denn damit genau
gemeint ist.
>> Hier eine meiner alten URLs, die so umleiten (eine von sehr vielen):
>>
>> <https://arnowelzel.de/wiki/de/fahrrad/>
[...]
> Ja, das ist der triviale Fall, dass der ursprüngliche URL nach wie vor bei
> einem Server unter der eigenen Regie landet. Bei Aufgabe der bisherigen
> Domain wegen Providerwechsel ist das nicht der Fall. Im nicht zitierten Teil
> meines Beitrags stand das im Absatz „Am leichtesten ...“.
Wenn Du mit "Providerwechsel" eigentlich "Änderung der Domain" meinst,
dann sag' das auch so.
Aber auch mit einer anderen Domain wäre die einer Umleitung zu einem
*anderen* Server exakt genauso. Was im Location-Header drinsteht, ist
völlig egal.
[...]
Dazu gibt es keine Lösung, egal wie die Umleitungen vorher erfolgt sind.
Ein "Providerwechsel" bedingt auch nicht, dass man die Domain kündigen
muss. Man kann auch einfach mit der Domain umziehen und nur das Hosting
kündigen. Angesichts des Umstands, dass z.B. de-Domains weniger als 5
EUR im Jahr kosten, wäre auch das Beibehalten der alten Domain
finanziell kein unlösbares Problem.
Generell empfehle ich, für Domain-Registrierung und Hosting verschiedene
Anbieter zu nehmen. Ich habe z.B. Domains bei INWX und Hosting bei
Netcup. Sollte irgendwann das Bedürfnis entstehen, mit einer Domain von
Netcup woanders hin umzuziehen, muss ich nur die IP-Adresse(n) bei INWX
anpassen, wenn ich mit Webspace oder Server woanders hin umziehen will.
Siehe auch: <https://www.inwx.de/de>
Die Umleitung erfolgt durch Header. Der Status ist dabei völlig egal und
gibt nur an, *warum* umgeleitet wurde - und das kann neben 301 eben auch
302, 303, 307 oder 201 sein.
Siehe auch:
<https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Location>
> Ich bitte „Umleitung per 301“ zu ersetzen durch das viel verständlichere
> „Umleitung durch Rückgabe eines HTTP-Status 301 mit zusätzlichem
> Location-Header, der den Ziel-URL angibt“. Dankenswerterweise hast du mir
> ja weiter unten erläutert, wie man das richtig macht.
erörtert, sollte man sich halt genau ausdrücken, um Mißverständnisse zu
vermeiden. Auch vermeidet man so Rückfragen, was denn damit genau
gemeint ist.
>> Hier eine meiner alten URLs, die so umleiten (eine von sehr vielen):
>>
>> <https://arnowelzel.de/wiki/de/fahrrad/>
> Ja, das ist der triviale Fall, dass der ursprüngliche URL nach wie vor bei
> einem Server unter der eigenen Regie landet. Bei Aufgabe der bisherigen
> Domain wegen Providerwechsel ist das nicht der Fall. Im nicht zitierten Teil
> meines Beitrags stand das im Absatz „Am leichtesten ...“.
dann sag' das auch so.
Aber auch mit einer anderen Domain wäre die einer Umleitung zu einem
*anderen* Server exakt genauso. Was im Location-Header drinsteht, ist
völlig egal.
[...]
> Neuer Zustand: der alte Server ist abgeschaltet
Du meinst eigentlich "Domain wurde gekündigt"? Dann hast Du verloren.
Dazu gibt es keine Lösung, egal wie die Umleitungen vorher erfolgt sind.
Ein "Providerwechsel" bedingt auch nicht, dass man die Domain kündigen
muss. Man kann auch einfach mit der Domain umziehen und nur das Hosting
kündigen. Angesichts des Umstands, dass z.B. de-Domains weniger als 5
EUR im Jahr kosten, wäre auch das Beibehalten der alten Domain
finanziell kein unlösbares Problem.
Generell empfehle ich, für Domain-Registrierung und Hosting verschiedene
Anbieter zu nehmen. Ich habe z.B. Domains bei INWX und Hosting bei
Netcup. Sollte irgendwann das Bedürfnis entstehen, mit einer Domain von
Netcup woanders hin umzuziehen, muss ich nur die IP-Adresse(n) bei INWX
anpassen, wenn ich mit Webspace oder Server woanders hin umziehen will.
Siehe auch: <https://www.inwx.de/de>
Thomas Hochstein
Dec 22, 2022, 6:30:02 PM12/22/22
to
Arno Welzel schrieb:
> Wenn Du mit "Providerwechsel" eigentlich "Änderung der Domain" meinst,
> dann sag' das auch so.
Ohne eigene Domain ist das einigermaßen zwingend synonym.
-thh
> Wenn Du mit "Providerwechsel" eigentlich "Änderung der Domain" meinst,
> dann sag' das auch so.
-thh
Thomas Hochstein
Dec 22, 2022, 6:30:02 PM12/22/22
to
Helmut Richter schrieb:
> On Wed, 21 Dec 2022, Thomas Hochstein wrote:
>> Marco Moock schrieb:
>>> Und die meisten URLs sind nach 20 Jahren nicht mehr gültig.
>> Viele halten nicht einmal 10 oder 5 Jahre.
>
> Für die von mir verwalteten Webauftritte möchte ich möglichst lange
> Gültigkeit von URLs erreichen, mindestens die Seiten nach 2012 sollen noch
> eine Weile auffindbar sein.
Ja, darum bemühe ich mich auch.
Die meisten Seiten meiner Homepage sind seit ~ 1997 bis heute erreichbar,
trotz Umzugs, verschiedener Umstrukturierungen, variierender Endungen (mal
.html, mal .php3, mal .php, jetzt nix) usw.
> Das ist ziemlicher Aufwand.
Ja, aber überschaubar. Es hängt natürlich davon ab, wie viele Seiten man
hat und wie oft und wie grundsätzlich man umstrukturiert. "Allgemeine"
Strukturänderungen lassen sich durch allgemeine Redirects oder Rewrites
auffangen, und so oft wird man vermutlich einzelne Seiten nicht ganz
woanders hin verschieben.
> Es ist leider
> technisch nicht immer ganz einfach, für die längere Gültigkeit des alten
> URL zu sorgen, wenn eine Seite umzieht, also einen neuen URL bekommt.
>
> Am leichtesten ist es, wenn alles am selben Server passiert oder an Servern,
> deren Verwalter dauerhaft kooperieren. Dann benutzt man den alten URL *nie*
> für eine andere Webseite als bisher und leitet per 301 um. Die alten Benutzer
> der Seite, die sich den alten URL gemerkt haben, werden das oft nicht
> bemerken und den alten URL möglicherweise jahrelang weiter benutzen.
>
> Will man das nicht oder hat man wegen Providerwechsels nur beschränkt lange
> Einfluss auf die Nutzung des alten URLs, kenne ich keine einfache Lösung.
Ah! Du meinst einen Umzug von einem Host auf den anderen. Da hilft
natürlich eine eigene Domain sehr.
Ich habe das dreimal durch (also zwei Umzüge):
Der erste Anbieter hat seinen Betrieb eingestellt, da half nix.
Dem zweiten Anbieter, einem Providerverein (ehemalige Regionaldomain des
Individual Network) zahle ich seit 2005 jeden Monat 8 EUR, damit die URLs
gültig bleiben. :) Die Umleitung erfolgt nicht automatisch, sondern durch
eine Hinweisseite auf den Umzug (mit Fehlercode 404), die die vermutliche
neue URL als Link ausgibt. Die Suchmaschinen haben die neuen Seiten
schnell "wiedergefunden", und so werden die alten Seiten nicht mehr
indiziert. Außerdem wird der Seitenaufruf und der Referrer geloggt, so
dass ich in den ersten Monaten / Jahren da ab und an mal durchschauen und
die Webseitenbetreiber mit den alten Links kontaktieren konnte.
Alle Umzüge und Umstrukturierungen danach waren egal; die Domain bleibt,
und die Änderungen von "Verzeichnissen" und "Dateinamen" lassen sich
abfangen.
-thh
> On Wed, 21 Dec 2022, Thomas Hochstein wrote:
>> Marco Moock schrieb:
>>> Und die meisten URLs sind nach 20 Jahren nicht mehr gültig.
>> Viele halten nicht einmal 10 oder 5 Jahre.
>
> Für die von mir verwalteten Webauftritte möchte ich möglichst lange
> Gültigkeit von URLs erreichen, mindestens die Seiten nach 2012 sollen noch
> eine Weile auffindbar sein.
Die meisten Seiten meiner Homepage sind seit ~ 1997 bis heute erreichbar,
trotz Umzugs, verschiedener Umstrukturierungen, variierender Endungen (mal
.html, mal .php3, mal .php, jetzt nix) usw.
> Das ist ziemlicher Aufwand.
Ja, aber überschaubar. Es hängt natürlich davon ab, wie viele Seiten man
hat und wie oft und wie grundsätzlich man umstrukturiert. "Allgemeine"
Strukturänderungen lassen sich durch allgemeine Redirects oder Rewrites
auffangen, und so oft wird man vermutlich einzelne Seiten nicht ganz
woanders hin verschieben.
> Es ist leider
> technisch nicht immer ganz einfach, für die längere Gültigkeit des alten
> URL zu sorgen, wenn eine Seite umzieht, also einen neuen URL bekommt.
>
> Am leichtesten ist es, wenn alles am selben Server passiert oder an Servern,
> deren Verwalter dauerhaft kooperieren. Dann benutzt man den alten URL *nie*
> für eine andere Webseite als bisher und leitet per 301 um. Die alten Benutzer
> der Seite, die sich den alten URL gemerkt haben, werden das oft nicht
> bemerken und den alten URL möglicherweise jahrelang weiter benutzen.
>
> Will man das nicht oder hat man wegen Providerwechsels nur beschränkt lange
> Einfluss auf die Nutzung des alten URLs, kenne ich keine einfache Lösung.
natürlich eine eigene Domain sehr.
Ich habe das dreimal durch (also zwei Umzüge):
Der erste Anbieter hat seinen Betrieb eingestellt, da half nix.
Dem zweiten Anbieter, einem Providerverein (ehemalige Regionaldomain des
Individual Network) zahle ich seit 2005 jeden Monat 8 EUR, damit die URLs
gültig bleiben. :) Die Umleitung erfolgt nicht automatisch, sondern durch
eine Hinweisseite auf den Umzug (mit Fehlercode 404), die die vermutliche
neue URL als Link ausgibt. Die Suchmaschinen haben die neuen Seiten
schnell "wiedergefunden", und so werden die alten Seiten nicht mehr
indiziert. Außerdem wird der Seitenaufruf und der Referrer geloggt, so
dass ich in den ersten Monaten / Jahren da ab und an mal durchschauen und
die Webseitenbetreiber mit den alten Links kontaktieren konnte.
Alle Umzüge und Umstrukturierungen danach waren egal; die Domain bleibt,
und die Änderungen von "Verzeichnissen" und "Dateinamen" lassen sich
abfangen.
-thh
Arno Welzel
Dec 22, 2022, 6:52:28 PM12/22/22
to
Thomas Hochstein, 2022-12-23 00:28:
Üblicherweise wird die Domain aber vom Kunden gemietet und nicht vom
Provider. Der Provider bekommt nur Geld dafür, die Registrierung
durchzuführen.
Provider. Der Provider bekommt nur Geld dafür, die Registrierung
durchzuführen.
Helmut Richter
Dec 23, 2022, 3:10:35 AM12/23/22
to
On Fri, 23 Dec 2022, Thomas Hochstein wrote:
> Dem zweiten Anbieter, einem Providerverein (ehemalige Regionaldomain des
> Individual Network) zahle ich seit 2005 jeden Monat 8 EUR, damit die URLs
> gültig bleiben. :) Die Umleitung erfolgt nicht automatisch, sondern durch
> eine Hinweisseite auf den Umzug (mit Fehlercode 404), die die vermutliche
> neue URL als Link ausgibt. Die Suchmaschinen haben die neuen Seiten
> schnell "wiedergefunden", und so werden die alten Seiten nicht mehr
> indiziert.
Das klingt nach einem Plan. Die Menschen werden durch den Status 404
> Dem zweiten Anbieter, einem Providerverein (ehemalige Regionaldomain des
> Individual Network) zahle ich seit 2005 jeden Monat 8 EUR, damit die URLs
> gültig bleiben. :) Die Umleitung erfolgt nicht automatisch, sondern durch
> eine Hinweisseite auf den Umzug (mit Fehlercode 404), die die vermutliche
> neue URL als Link ausgibt. Die Suchmaschinen haben die neuen Seiten
> schnell "wiedergefunden", und so werden die alten Seiten nicht mehr
> indiziert.
informiert, und solange der Zwischenzustand (alte Domain noch in Betrieb
für Umleitungen, Fehlermeldungen und Zertifikate, nicht mehr für
Nutzdaten) herrscht, kann man die 404-Fehlerseite auch so gestalten, dass
ein Mensch die neue Seite gleich findet. Und Suchmaschinen sollen
gefälligst selber suchen.
> Außerdem wird der Seitenaufruf und der Referrer geloggt, so
> dass ich in den ersten Monaten / Jahren da ab und an mal durchschauen und
> die Webseitenbetreiber mit den alten Links kontaktieren konnte.
selten was Neues im Refer[r]rer, was man nicht schon wusste. Ganz nebenbei
stecken hinter Links manchmal auch Menschen mit ähnlichen Interessen, die
man so kennenlernt.
--
Helmut Richter
Helmut Richter
Dec 23, 2022, 3:46:54 AM12/23/22
to
On Thu, 22 Dec 2022, Helmut Richter wrote:
> Was ich probiert habe und geht, ohne dass Benutzer des neuen URL mit für
> sie überflüssigen Hinweisen belästigt werden:
>
> – Umleitung per 301 an den neuen URL mit Angabe eines Fragmentbezeichners
> (im Beispiel „badURL“), der auf einen Hinweis zeigt, der per CSS nur
> dann angezeigt wird, wenn er benutzt wird:
> Beispiel: lochhausener-singkreis.userweb.mwn.de (ausprobieren)
Ja, wie man am Beispiel sieht, geht das, solange die alte Domain noch
> Was ich probiert habe und geht, ohne dass Benutzer des neuen URL mit für
> sie überflüssigen Hinweisen belästigt werden:
>
> – Umleitung per 301 an den neuen URL mit Angabe eines Fragmentbezeichners
> (im Beispiel „badURL“), der auf einen Hinweis zeigt, der per CSS nur
> dann angezeigt wird, wenn er benutzt wird:
> Beispiel: lochhausener-singkreis.userweb.mwn.de (ausprobieren)
einen Server hat, der wenigstens ein Zertifikat für HTTPS vorlegt und eine
Umleitung anstößt oder eine Fehlermeldung ausspuckt.
> Was ich noch ausprobieren möchte:
>
> – Umleitung per 301 an den neuen URL mit Angabe des vom Nutzer
> verwendeten URL im Fragmentbezweichner: Man kann dann den Hinweis an den
> Benutzer flexibler gestalten und die Fälle „Seite liegt serverrelativ am
> gleichen Ort“, „Seite ist noch (=wieder) da, hat aber geänderten
> dauerhaften Pfad“, „Seite ist noch da, aber auf provisorischen Pfad“ nach
> einheitlichen Algorithmen abhandeln, die auf leicht änderbare Daten
> zugreifen.
Gesicht bekommt. Das funktioniert nur, wenn er das wie im vorher genannten
Verfahren gar nicht muss. Ich werde es nicht weiter verfolgen.
Im Übrigen hat mich Thomas Hochstein überzeugt, dass man sich
hauptsächlich um die Information der menschlichen Benutzer kümmern muss,
die den veralteten URL benutzen, und weniger um Suchmaschinen.
--
Helmut Richter
Arno Welzel
Dec 23, 2022, 5:26:30 AM12/23/22
to
Thomas Hochstein, 2022-12-23 00:17:
[...]
im Monat und realistisch kann ich das Hosting ab ca. 1 EUR im Monat
betreiben.
[...]
> Dem zweiten Anbieter, einem Providerverein (ehemalige Regionaldomain des
> Individual Network) zahle ich seit 2005 jeden Monat 8 EUR, damit die URLs
> gültig bleiben. :) Die Umleitung erfolgt nicht automatisch, sondern durch
Wieviele Domains sind das denn? Hier zahle ich pro Domain ca. 0,40 EUR
> Individual Network) zahle ich seit 2005 jeden Monat 8 EUR, damit die URLs
> gültig bleiben. :) Die Umleitung erfolgt nicht automatisch, sondern durch
im Monat und realistisch kann ich das Hosting ab ca. 1 EUR im Monat
betreiben.
Hartmut Kraus
Dec 23, 2022, 7:29:19 AM12/23/22
to
Am 22.12.22 um 11:19 schrieb Helmut Richter:
Frag' mal den, solche Lösungen gehören zu seinem Geschäft:
in...@benjamin-mylius.de
(Keine Sorge, diese Mailadresse hat er selber auf seiner Website veröffentlicht.) Die Seite überarbeitet er gerade:
https://www.benjamin-mylius.de/
--
http://hkraus.eu/hk/Profil.pdf
in...@benjamin-mylius.de
(Keine Sorge, diese Mailadresse hat er selber auf seiner Website veröffentlicht.) Die Seite überarbeitet er gerade:
https://www.benjamin-mylius.de/
--
http://hkraus.eu/hk/Profil.pdf
Thomas Hochstein
Dec 23, 2022, 5:30:03 PM12/23/22
to
Stefan Ram schrieb:
> Ich würde jedenfalls sagen, daß solche Änderungen wie 2018 von
>
> http://www.dana.de/mod/checkgroups.txt
>
> nach
>
> http://www.dana.de/checkgroups.txt
>
> Aufwand ohne Nutzen verursachen, soweit ich das jetzt von hier
> aus erkennen kann.
Nein, das macht schon Sinn. IIRC war ursprünglich angedacht, die Domain
als zentrale Anlaufstelle für das deutschsprachige Usenet zu verwenden, so
dass die Seiten der Moderation von de.admin.news.announce nur einen Teil
des Angebots bilden. Dazu kam es nie, daher ist der Entfall der
Pfadkomponente sinnvoll.
> Cool URIs don't change
Ein Redirect oder Rewrite täte not, ja. Sollte auch trivial sein. Muss
halt mal jemand machen.
> Ich würde jedenfalls sagen, daß solche Änderungen wie 2018 von
>
> http://www.dana.de/mod/checkgroups.txt
>
> nach
>
> http://www.dana.de/checkgroups.txt
>
> Aufwand ohne Nutzen verursachen, soweit ich das jetzt von hier
> aus erkennen kann.
Nein, das macht schon Sinn. IIRC war ursprünglich angedacht, die Domain
als zentrale Anlaufstelle für das deutschsprachige Usenet zu verwenden, so
dass die Seiten der Moderation von de.admin.news.announce nur einen Teil
des Angebots bilden. Dazu kam es nie, daher ist der Entfall der
Pfadkomponente sinnvoll.
> Cool URIs don't change
Ein Redirect oder Rewrite täte not, ja. Sollte auch trivial sein. Muss
halt mal jemand machen.
Thomas Hochstein
Dec 23, 2022, 5:30:03 PM12/23/22
to
Arno Welzel schrieb:
> Thomas Hochstein, 2022-12-23 00:17:
>
(analog oder ISDN, wobei ich denke, analog geht nicht mehr), UUCP, Mail,
News, Webseite, Shell-Account, wie sich das eben gehört. :)
> Thomas Hochstein, 2022-12-23 00:17:
>
>> Dem zweiten Anbieter, einem Providerverein (ehemalige Regionaldomain des
>> Individual Network) zahle ich seit 2005 jeden Monat 8 EUR, damit die URLs
>> gültig bleiben. :)
>
>> Individual Network) zahle ich seit 2005 jeden Monat 8 EUR, damit die URLs
>> gültig bleiben. :)
>
> Wieviele Domains sind das denn?
Kein solch neumodischer Schnickschnack wie Domains. Inkludiert ist Dialup
(analog oder ISDN, wobei ich denke, analog geht nicht mehr), UUCP, Mail,
News, Webseite, Shell-Account, wie sich das eben gehört. :)
Arno Welzel
Dec 24, 2022, 1:31:50 AM12/24/22
to
Thomas Hochstein, 2022-12-23 23:22:
Eine URL bedingt aber eine Domain.
Arno Welzel
Dec 24, 2022, 1:33:07 AM12/24/22
to
Stefan Ram, 2022-12-23 22:52:
> Thomas Hochstein <t...@thh.name> writes:
>> Ja, aber überschaubar. Es hängt natürlich davon ab, wie viele Seiten man
>> hat und wie oft und wie grundsätzlich man umstrukturiert. "Allgemeine"
>> Strukturänderungen lassen sich durch allgemeine Redirects oder Rewrites
>> auffangen, und so oft wird man vermutlich einzelne Seiten nicht ganz
>> woanders hin verschieben.
>
> mal wieder die Regale umräumen zu müssen. Für mich gilt:
technischen Gründen nicht vermeiden lässt. Idealerweise bildet man URLs
*nicht* auf ein Dateisystem ab, sondern hat ein CMS, was die URL nur als
Parameter bekommt und den dazu passenden Inhalt liefert.
> Thomas Hochstein <t...@thh.name> writes:
>> Ja, aber überschaubar. Es hängt natürlich davon ab, wie viele Seiten man
>> hat und wie oft und wie grundsätzlich man umstrukturiert. "Allgemeine"
>> Strukturänderungen lassen sich durch allgemeine Redirects oder Rewrites
>> auffangen, und so oft wird man vermutlich einzelne Seiten nicht ganz
>> woanders hin verschieben.
>
> Ich würde jedenfalls sagen, daß solche Änderungen wie 2018 von
>
> http://www.dana.de/mod/checkgroups.txt
>
> nach
>
> http://www.dana.de/checkgroups.txt
>
> Aufwand ohne Nutzen verursachen, soweit ich das jetzt von hier
> aus erkennen kann. Das ist wie, wenn der Supermarkt meint,
>
> http://www.dana.de/mod/checkgroups.txt
>
> nach
>
> http://www.dana.de/checkgroups.txt
>
> Aufwand ohne Nutzen verursachen, soweit ich das jetzt von hier
> mal wieder die Regale umräumen zu müssen. Für mich gilt:
>
> Cool URIs don't change
Deswegen gibt es ja auch Weiterleitungen, wenn sich eine Änderung aus
> Cool URIs don't change
technischen Gründen nicht vermeiden lässt. Idealerweise bildet man URLs
*nicht* auf ein Dateisystem ab, sondern hat ein CMS, was die URL nur als
Parameter bekommt und den dazu passenden Inhalt liefert.
Enrik Berkhan
Dec 24, 2022, 3:33:06 AM12/24/22
to
>> Kein solch neumodischer Schnickschnack wie Domains. Inkludiert ist Dialup
>> (analog oder ISDN, wobei ich denke, analog geht nicht mehr), UUCP, Mail,
>> News, Webseite, Shell-Account, wie sich das eben gehört. :)
>
> Eine URL bedingt aber eine Domain.
Aber nicht zwingend 2nd level.
>> (analog oder ISDN, wobei ich denke, analog geht nicht mehr), UUCP, Mail,
>> News, Webseite, Shell-Account, wie sich das eben gehört. :)
>
> Eine URL bedingt aber eine Domain.
Gruß,
Enrik
Stefan Froehlich
Dec 24, 2022, 3:52:28 AM12/24/22
to
On Sat, 24 Dec 2022 07:33:05 Arno Welzel wrote:
> Idealerweise bildet man URLs *nicht* auf ein Dateisystem ab,
> sondern hat ein CMS, was die URL nur als Parameter bekommt und den
> dazu passenden Inhalt liefert.
Idealerweise gestaltet man das abhängig von den Anforderungen der
> Idealerweise bildet man URLs *nicht* auf ein Dateisystem ab,
> sondern hat ein CMS, was die URL nur als Parameter bekommt und den
> dazu passenden Inhalt liefert.
jeweiligen Seite.
Bei den größeren Applikationen mit Mannjahren Entwicklungsarbeit hat
die URL-Struktur natürlich nichts mit einem Dateisystem und dessen
Strukturen zu tun. Meine "Homepage" mit ein paar Dutzend statischen
Seiten und einer Handvoll Urlaubsfotos: Da wäre ein CMS, egal
welches, technischer Overkill, würde laufend Support verursachen und
im schlimmsten Fall noch Sicherheitslücken schaffen. Weshalb sollte
ich mir das antun?
Servus,
Stefan
--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike
Stefan - Das hätte man sich aber auch vorher denken können!
(Sloganizer)
Arno Welzel
Dec 24, 2022, 10:15:16 AM12/24/22
to
Stefan Froehlich, 2022-12-24 09:52:
> On Sat, 24 Dec 2022 07:33:05 Arno Welzel wrote:
>> Idealerweise bildet man URLs *nicht* auf ein Dateisystem ab,
>> sondern hat ein CMS, was die URL nur als Parameter bekommt und den
>> dazu passenden Inhalt liefert.
>
> Idealerweise gestaltet man das abhängig von den Anforderungen der
> jeweiligen Seite.
>
> Bei den größeren Applikationen mit Mannjahren Entwicklungsarbeit hat
> die URL-Struktur natürlich nichts mit einem Dateisystem und dessen
> Strukturen zu tun. Meine "Homepage" mit ein paar Dutzend statischen
> Seiten und einer Handvoll Urlaubsfotos: Da wäre ein CMS, egal
> welches, technischer Overkill, würde laufend Support verursachen und
> im schlimmsten Fall noch Sicherheitslücken schaffen. Weshalb sollte
> ich mir das antun?
Das "CMS" kann auch ein einziges Script sein, was lediglich das Mapping
von URL zur realen Datei macht.
> On Sat, 24 Dec 2022 07:33:05 Arno Welzel wrote:
>> Idealerweise bildet man URLs *nicht* auf ein Dateisystem ab,
>> sondern hat ein CMS, was die URL nur als Parameter bekommt und den
>> dazu passenden Inhalt liefert.
>
> Idealerweise gestaltet man das abhängig von den Anforderungen der
> jeweiligen Seite.
>
> Bei den größeren Applikationen mit Mannjahren Entwicklungsarbeit hat
> die URL-Struktur natürlich nichts mit einem Dateisystem und dessen
> Strukturen zu tun. Meine "Homepage" mit ein paar Dutzend statischen
> Seiten und einer Handvoll Urlaubsfotos: Da wäre ein CMS, egal
> welches, technischer Overkill, würde laufend Support verursachen und
> im schlimmsten Fall noch Sicherheitslücken schaffen. Weshalb sollte
> ich mir das antun?
von URL zur realen Datei macht.
Thomas Hochstein
Dec 24, 2022, 12:45:02 PM12/24/22
to
Arno Welzel schrieb:
> Thomas Hochstein, 2022-12-23 23:22:
> > Arno Welzel schrieb:
> Thomas Hochstein, 2022-12-23 23:22:
> > Arno Welzel schrieb:
>>> Wieviele Domains sind das denn?
>>
>> Kein solch neumodischer Schnickschnack wie Domains. Inkludiert ist Dialup
>> (analog oder ISDN, wobei ich denke, analog geht nicht mehr), UUCP, Mail,
>> News, Webseite, Shell-Account, wie sich das eben gehört. :)
>
> Eine URL bedingt aber eine Domain.
Ja, klar. Der Anbieter hat eine Domain, und darunter finden sich die
>>
>> Kein solch neumodischer Schnickschnack wie Domains. Inkludiert ist Dialup
>> (analog oder ISDN, wobei ich denke, analog geht nicht mehr), UUCP, Mail,
>> News, Webseite, Shell-Account, wie sich das eben gehört. :)
>
> Eine URL bedingt aber eine Domain.
Webseiten der Kunden - "home.t-online.de/home/NAME", oder
"members.aol.com/NAME", oder "sites.inka.de/NAME", oder ...
Arno Welzel
Dec 24, 2022, 2:34:32 PM12/24/22
to
Thomas Hochstein, 2022-12-24 18:37:
Aus Fehlern lernt man... ;-)
Stefan Froehlich
Dec 25, 2022, 4:21:45 AM12/25/22
to
On Sat, 24 Dec 2022 16:15:13 Arno Welzel wrote:
>> Meine "Homepage" mit ein paar Dutzend statischen Seiten und einer
>> Handvoll Urlaubsfotos: Da wäre ein CMS, egal welches, technischer
>> Overkill, würde laufend Support verursachen und im schlimmsten
>> Fall noch Sicherheitslücken schaffen. Weshalb sollte ich mir das
>> antun?
> Das "CMS" kann auch ein einziges Script sein, was lediglich das
> Mapping von URL zur realen Datei macht.
Selbst das wäre (mir) schon zu viel. Mehr als ein paar Tippfehler
>> Meine "Homepage" mit ein paar Dutzend statischen Seiten und einer
>> Handvoll Urlaubsfotos: Da wäre ein CMS, egal welches, technischer
>> Overkill, würde laufend Support verursachen und im schlimmsten
>> Fall noch Sicherheitslücken schaffen. Weshalb sollte ich mir das
>> antun?
> Das "CMS" kann auch ein einziges Script sein, was lediglich das
> Mapping von URL zur realen Datei macht.
bessere ich auf bereits bestehenden Seiten wohl niemals mehr aus.
Servus,
Stefan
--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike
(Sloganizer)
Arno Welzel
Dec 25, 2022, 1:36:46 PM12/25/22
to
Stefan Ram, 2022-12-24 23:25:
> Thomas Hochstein <t...@thh.name> writes:
>> Arno Welzel schrieb:
>>> Thomas Hochstein, 2022-12-23 23:22:
>>>> Arno Welzel schrieb:
> HTTP-URI ohne Domänennamen. Der /host identifier/ (RFC 9110)
> ist dort "127.0.0.1", er ist Teil einer authority (RFC 9110)
> welche ein scheme (RFC 2717) darstellt.
Wie oft kommt es vor, dass Endkunden Websites in dieser Form ohne Domain
haben?
> Thomas Hochstein <t...@thh.name> writes:
>> Arno Welzel schrieb:
>>> Thomas Hochstein, 2022-12-23 23:22:
>>>> Arno Welzel schrieb:
>>>> Kein solch neumodischer Schnickschnack wie Domains. Inkludiert ist Dialup
>>>> (analog oder ISDN, wobei ich denke, analog geht nicht mehr), UUCP, Mail,
>>>> News, Webseite, Shell-Account, wie sich das eben geh?rt. :)
>>>> (analog oder ISDN, wobei ich denke, analog geht nicht mehr), UUCP, Mail,
>>> Eine URL bedingt aber eine Domain.
>> Ja, klar. Der Anbieter hat eine Domain, und darunter finden sich die
>> Webseiten der Kunden - "home.t-online.de/home/NAME", oder
>> "members.aol.com/NAME", oder "sites.inka.de/NAME", oder ...
>
> "http://127.0.0.1/index.html" wäre beispielsweise eine
>> Ja, klar. Der Anbieter hat eine Domain, und darunter finden sich die
>> Webseiten der Kunden - "home.t-online.de/home/NAME", oder
>> "members.aol.com/NAME", oder "sites.inka.de/NAME", oder ...
>
> HTTP-URI ohne Domänennamen. Der /host identifier/ (RFC 9110)
> ist dort "127.0.0.1", er ist Teil einer authority (RFC 9110)
> welche ein scheme (RFC 2717) darstellt.
Wie oft kommt es vor, dass Endkunden Websites in dieser Form ohne Domain
haben?
0 new messages