Semi-Automated edit - adding "/" at the end to URLs

OSM_RogerWilco · 2024-07-26T07:38:47.837Z

flohoff:

Wenn du es kopierst ist es da.

Genau das hat @localhorst auch geschrieben.

Bei Firefox 128.0 (Linux Mint) übrigens das selbe Verhalten.

FraukeLeo · 2024-07-26T07:59:08.803Z

Und was soll damit belegt oder bewiesen werden, ob ein Browser einen Slash hinten dranmacht oder nicht?

Beide Schreibweisen sind vollkommen gleichwertig, wie gezeigt wurde. Wenn jemand die URL aus dem Browser kopiert, dann ist halt ein Slash hinten, und wenn ein anderer sie eintippt, dann nicht. So what? Das kann doch so bleiben.

Ich sehe weiterhin keinen Grund für eine flächendeckende Angleichung.

OSM_RogerWilco · 2024-07-26T08:02:10.379Z

FraukeLeo:

Ich sehe weiterhin keinen Grund für eine flächendeckende Angleichung.

Diese Erkenntnis wird in meinen Augen durch dieses Browserverhalten unterstützt.

Aber Du hast Recht. Was andere Software macht, sollte uns egal sein, wenn es darum geht, wie wir Daten in die OSM-Datenbank eintragen. Und da denke ich, gibt es kein Konsens, dass der abschließende Schrägstrich zwingend einzutragen ist.

Das sollte im Wiki dokumentiert werden. Die Frage ist, ob nur für Deutschland oder auch im internationalen Wiki. Ich weiß nicht auf welcher Grundlage die Formatierung damals so im Wiki eingetragen wurde.

Jörg_Roßdeutscher · 2024-07-26T20:20:19.959Z

Viel kritischer als die Frage nach dem Slash fand ich auch eigentlich auch solche Themen aus der Ankündigung:

localhorst:

und solchen Sachen wie http://www.exampe.org/startseite oder http://www.exampe.org/willkommen.html, wo die Server selbst drauf weiterleiten. wenn man die Rootseite aufruft, ausgenommen natürlich echte Deeplinks

Ich verstehe das so, dass, wenn wir hinterlegte haben:
http://example.com
, und bei einem Aufruf der Seite käme es zu Umleitungen…

von http auf https
von “ohne Subdomain” auf “www”
von “/” auf “/startseite.html”
…, dass Du dann den Eintrag ändern willst auf das Umleitungsziel “https://www.example.com/startseite.html”, nur weil das hier und heute darauf umleitet.

Ich bin der Meinung, wenn auf dem Firmenschild steht “http://example.com”, dass das dann die gültige URL ist. Und nicht, was tagesaktuell hinten rauskommt, wenn man das eingibt.

Bei Deeplinks mag das korrekt sein. Die Adresse der Harzer Wandernadel Nummer 123 oder ein Link in die Wikipedia hat sich ggf. verändert, OK, das kann man updaten. Aber nicht den Einstieg in eine “nackte” Domain.

localhorst · 2024-07-26T20:45:36.962Z

Jörg_Roßdeutscher:

Viel kritischer als die Frage nach dem Slash fand ich auch eigentlich auch solche Themen aus der Ankündigung:

localhorst:

und solchen Sachen wie http://www.exampe.org/startseite oder http://www.exampe.org/willkommen.html, wo die Server selbst drauf weiterleiten. wenn man die Rootseite aufruft, ausgenommen natürlich echte Deeplinks

Ich verstehe das so, dass, wenn wir hinterlegte haben:
http://example.com
, und bei einem Aufruf der Seite käme es zu Umleitungen…

von http auf https

von “ohne Subdomain” auf “www”

von “/” auf “/startseite.html”
…, dass Du dann den Eintrag ändern willst auf das Umleitungsziel “https://www.example.com/startseite.html”, nur weil das hier und heute darauf umleitet.

Ich bin der Meinung, wenn auf dem Firmenschild steht “http://example.com”, dass das dann die gültige URL ist. Und nicht, was tagesaktuell hinten rauskommt, wenn man das eingibt.

Ich glaube, das hast du falsch verstanden.

Wenn es zu Redirects kommt von http zu https oder von mit/ohne www zu ohne/mit www ändere ich das, weil das ist ja offensichtlich der Wille des Betreibers.

Aber bei Redirects von http://www.example.org/ zu http://www.example.org/startseite etc. trage ich nur http://www.example.org/ ein bzw. Einträge mit http://www.example.org/startseite ändere ich, weil das kommt ja dann vom WCMS. Und das hat den Vorteil, dass es dann immer noch funktioniert, wenn sich das WCMS und damit der Redirect ändert.

Echte Deeplinks wie https://www.verwaltungsgemeinschaft.de/mitgliedsgemeinde/ortsname/ bleiben (http(s) und www werden natürlich angepasst, wenn erforderlich).

Edit: Bei Redirects auf eine andere/neue Domain trage ich die neue Domain ein, weil nicht klar ist, wie lange der Betreiber die alte Domain noch für Redirects am Leben erhält. Das ist ja auch eine bewusste Entscheidung des Betreibers, die Domain zu wechseln.

a_d_s · 2024-07-26T20:50:48.343Z

localhorst:

Aber bei Redirects von http://www.example.org/ zu http://www.example.org/startseite etc. trage ich nur http://www.example.org/ ein bzw. Einträge mit http://www.example.org/startseite ändere ich, weil das kommt ja dann vom WCMS. Und das hat den Vorteil, dass es dann immer noch funktioniert, wenn sich das WCMS und damit der Redirect ändert.

Der Link funktioniert auch heute mit dem Redirect. Das möge heute CMS sein, morgen eine statische Webseite. Übermorgen etwas ganz anderes. Es obliegt dem Betreiber der Webseite wie die Inhalte dargestellt werden.

habi · 2024-07-26T21:02:02.468Z

localhorst:

URLs die mittlerweile von http zu https migriert sind

Es ist unnötig, http manuell zu https zu ändern, wenn eine Migration des Webservers erfolgt ist.
Das macht schon der b-jazz-bot.

trial · 2024-07-26T21:23:16.000Z

localhorst:

gewöhnlicherweise

Ganz genau: / ist kein Muß.

BrummsLee · 2024-07-26T22:02:21.482Z

Wenn ich mal eine Website-Adresse korrigiere, dann entferne ich grundsätzlich das “slash” Zeichen am Ende. Auch Firefox hängt es beim Kopieren der Url mit an.
Ich kenne solche Internetadressen aus meiner
Vergangenheit nicht.
Aus diesem Grund entferne ich grundsätzlich einen solchen “Slash” Strich.
Bei mir kommt die Url nur ohne Slash in die Datenbank!

localhorst · 2024-07-26T23:59:16.643Z

Dein Argument, dass du etwas nicht kennst, ist ziemlich schwach. Dass Firefox den Schrägstrich beim Kopieren anhängt, ist eher ein Argument für seine Beibehaltung als für seine Entfernung. Browser implementieren oft Best Practices.

Jörg_Roßdeutscher · 2024-07-27T06:01:20.221Z

localhorst:

Ich glaube, das hast du falsch verstanden.

Ne, ich glaube, man kann das fast alles unter einem Satz zusammenfassen:

Du möchtest in OSM persistieren, was “der Server macht” oder “was in einem RFC als best practice dokumentiert ist” oder “was Du im Web vorfindest”

Und ich möchte, dass in OSM steht, was “on the ground” auf Firmenschildern, Speisekarten etc. steht.

Wir sollten dem folgen, was der Laden ausschildert. Es steht im Ermessen des Betreibers, wieder auf http zurückzufallen, weil er sich grad kein neues Zertifikat leisten kann. In Migrationsphasen kann ein www oder ein Pfad auch mal kaputt sein oder es kommt jetzt doch anders. Redirects auf andere Domains sind ein klares Zeichen, dass sich gerade was ändert, und wenn das wirklich dauerhaft gewollt ist, dann wird das früher oder später auf dem Firmenschild landen, und dann tragen wir es ein.

Kurzform:

URLs sollten sein wie OTG beschildert
Wir schreiben “dumm” ab, was der Betreiber kommuniziert

In Sonderfällen (Website liefert längere Zerit 404, oder vor Ort werden grad die Firmenschilder ausgetauscht) kann man gern das Beste draus machen, dass die Welt dynamisch ist.

Aber in Normalfall hat m.M.n. die Willensbekundung des Betreibers Vorrang.

Jörg_Roßdeutscher · 2024-07-27T06:07:18.496Z

(technischer Einschub zum Slash): Bei mir wird bei CopyPaste übrigens kein Slash angehängt. Das liegt möglicherweise daran, dass ich in meinen Browsern die exakte Darstellung von URLs aktiviert habe (Rechtsklick auf Location Bar, dann Haken setzen bei “Vollständige Adresse zeigen” in Chrome. Firefox hat das ebenfalls irgendwo)
Ist meines Erachtens aber eh egal, weil wir OTG mappen, und nicht “was Chrome gut findet”

OSM_RogerWilco · 2024-07-27T06:22:29.781Z

Das sehe ich nicht so. Bei Telefonnummern übernehmen wir auch nicht die OTG Schreibweise, sondern fügen z.B. die Ländervorwahl an.

Bei Emailadressen ersetzen wir ein “at” durch @.

Das hat aber technische Gründe, die auch eine Relevanz haben.

Bei Namen diskutieren wir auch, ob wir die OTG Schreibweise “PENNY.” übernehmen oder “Penny” in die Datenbank schreiben. Aber da erlauben wir auch nicht, dass jemand alle Namen nach seinem bervorzugten Schema anpasst, sondern akzeptieren beide Lösungen.

flohoff · 2024-07-27T07:26:17.718Z

OSM_RogerWilco:

Das sehe ich nicht so. Bei Telefonnummern übernehmen wir auch nicht die OTG Schreibweise, sondern fügen z.B. die Ländervorwahl an.

DAS ist aber was anderes das wir auf e.164/enum schreibweise umschreiben.

Das wäre so als würden wir bei allen deutschen domains das “.de” weglassen und sagen das du dir das ja über die boundary für Deutschland holen kannst.

Wir machen durch das anfügen der +49 Länderkennziffer erst überhaupt einen ein-eindeutiges rufnummer draus - also wenn du so willst eine vollständige URI. Oder die Länderkennziffer wäre keine internationale ein-eindeutigkeit gegeben.

DAS ist beim “/” anfügen am ende nicht so - das wäre so als wenn du sagst wir hätten gerne das rufnummern zwischen der länderkennziffer und der rufnummer ein space haben müssen (oder auch nicht).

Technisch völlig irrelevant ob das da ist oder nicht.

Flo

OSM_RogerWilco · 2024-07-27T07:33:11.399Z

flohoff:

DAS ist aber was anderes

Ja genau. Schrieb ich ja.

Fjellrev · 2024-07-27T08:26:41.912Z

IMHO eine absolut unnötige (und unschöne) Anpassung.
Dass es dem Browser so etwas von egal ist dürfte ja mittlerweile klar sein ausser man will es nicht wahrhaben…
Aber es verschlechtert auch die Lesbarkeit für den menschlichen Anwender.
Von daher: Ohne / am Ende denn funktionell bringt es nichts und der Optik schadet es.

Minh_Nguyen · 2024-07-27T22:59:58.106Z

Punycode: 376
Internationalisierte Domainnamen: 2453

localhorst · 2024-07-28T04:10:12.315Z

Jörg_Roßdeutscher:

Und ich möchte, dass in OSM steht, was “on the ground” auf Firmenschildern, Speisekarten etc. steht.

Wir sollten dem folgen, was der Laden ausschildert.

Das ist doch vollkommen weltfremd. Wer schreibt URLs von Visitenkarten oder Firmenschildern ab? Wenn ich nach einer Webpräsenz einer Stadt, Gemeinde oder Firma suche, dann nutze ich die Suchmaschine meines Vertrauens. Und das, was mir die Suchmaschine anbietet, untersuche ich dann näher. Und daran bzw. was mir der Webserver präsentiert, orientiere ich mich. Und nicht an irgendwelchen Visitenkarten, die mir gar nicht vorliegen und die vielleicht längst veraltet sind.

localhorst · 2024-07-28T04:21:01.239Z

Fjellrev:

Aber es verschlechtert auch die Lesbarkeit für den menschlichen Anwender.
Von daher: Ohne / am Ende denn funktionell bringt es nichts und der Optik schadet es.

Dan nenne mir mal so drei, vier wissenschaftliche Studien, die alle unabhängig voneinander belegen, dass der “/” am Ende des Hostnamens die Lesbarkeit für den menschlichen Anwender verschlechtert und der Optik schadet.

FraukeLeo · 2024-07-28T05:29:52.574Z

localhorst:

Studien, die alle unabhängig voneinander belegen, dass der “/” am Ende des Hostnamens die Lesbarkeit für den menschlichen Anwender verschlechtert

Nee, andersrum. Du willst die Änderung durchsetzen, also nenn du uns mal die Vorteile, die diese Änderung bringt. Gern auch anhand von drei, vier wissenschaftlichen Studien, die das alle unabhängig voneinander belegen. Ich sehe bis jetzt noch keine, und Ändern um des Änderns willen ist reines Changeset-Sammeln. Jede Änderung in OSM sollte eine Verbesserung sein (und nein, ich werde diesen Satz jetzt nicht mit drei, vier unabhängigen wissenschaftlichen Studien belegen).