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

flohoff · 2024-07-25T09:40:44.605Z

Ja bitte - Und gerne mit verweis auf der RFC zu URIs:

RFC 3986: Uniform Resource Identifier (URI): Generic Syntax

A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form,...

Das besagt eben das mit und ohne traling “/” - Also empty path - equivalent sind.

Erst im falle einer Normalisierung bei technische Anforderungen - wenn die URI als index für einen Cache benutzt wird z.b. soll das “/” immer verwendet werden um cache aliasing zu vermeiden.

Flo

flohoff · 2024-07-25T09:54:24.797Z

seichter:

Die Anzeige von Weblinks wird nur von Browsern gemacht, das Protokoll dazu ist festgelegt.
Add.: Gängige Browser können optional darüber hinausgehen und ein http(s):// und sogar ein www vor der Domain versuchsweise einsetzen. Das kommt aus der Zeit, als man noch Webadressen in die Eingabezeile eingeschrieben hat und dem User Tipperei abnehmen wollte.

Aeh naja - Es gibt ein RFC für URIs das sagt was Bestandteil des “Uniform Resource Identifier” ist - Was die Browser da machen - das sie das http ausblenden steht nirgends und ICH halte das auch für eine ziemlich schlimme user interface “verbesserung”.

Das RFC3986 sagt das der “link” oder die “URI” eben ein scheme, eine domain/host und einen path beinhaltet (und noch mehr Gemüse wie den Anchor und co). Dabei kann der path leer sein.

Das darunterliegende Protokoll um dann ein Object - identifiziert durch eine URI via HTTP anzufragen (URIs sind nicht nur HTTP) ist dann allerdings so konzipiert das der path nicht mehr leer sein kann weil in der zeile ein path drin sein MUSS.

Deshalb ist im HTTP RFC definiert das wenn der path “leer” ist das zu Deutsch Wurzelverzeichnis (schudder) “/” angefragt werden soll wenn der path leer ist.

D.h. aus “http://www.dom.ain” wird ein request auf “/” auf dem Host “www.dom.ain” - Das macht alles die HTTP konforme appliikation - also der Browser - für dich.

Der generische URI RFC sagt auch das wenn die URI als Index verwendet wird z.b. im Browser Cache, oder es Verwechslungsgefahr geben könnte URIs normalisiert werden können. Dann soll ein “/” angehängt werden - wobei das RFC klar darin ist das “http://www.dom.ain” und “http://www.dom.ain/” equivalent sind.

Das sind identische URIs und brauchen keinen “/”.

Dazu kommt das nichtmal die Browser einheitlich sind wie sie die URI anzeigen oder transformieren:

Chrome: Entfernt trailing “/” nach dem Return
Firefox (115ESR): Fügt einen “/” an und zeigt den auch an
Brave: Wie chrome
Chromium: Wie chrome

D.h. wenn jetzt da “/” angefügt werden - ein user drauf klickt mit Chrome (80%? der Browser) ist der “/” weg. Wenn der dann die URI nimmt wieder rein kopiert bleibt er weg.

Also jetzt das “/” anzufügen ist totaler unsinn - Beim nächsten mal sind die wieder weg.

Daher ja auch das klare NACK für diesen mechanischen edit von mir.

Flo

Jörg_Roßdeutscher · 2024-07-25T19:17:06.652Z

Danke für die Infos.

Ich denke, wir sollten nichts “korrigieren”, was “on the ground” so angegeben ist.

Wenn ein Shop “Melanie’s Blumenladen” heißt, dann heißt er so, da machen wir auch kein Apostroph weg.

Links auf Wikipedia o.ä. sind was anderes, aber wenn eine Firma ihre eigene Adresse als http ohne s , mit-oder-ohne www und mit-oder-ohne Slash angibt, und die Website ist damit erreichbar, dann ist das so.

localhorst · 2024-07-25T19:53:42.844Z

flohoff:

D.h. wenn jetzt da “/” angefügt werden - ein user drauf klickt mit Chrome (80%? der Browser) ist der “/” weg. Wenn der dann die URI nimmt wieder rein kopiert bleibt er weg.

Nö. Chrome zeigt den “/” in der Adresszeile zwar nicht an, wenn man die URL aber aus der Adresszeile rauskopiert und wo anders einfügt, ist der “/” dran.

flohoff · 2024-07-26T07:13:18.126Z

localhorst:

Nö. Chrome zeigt den “/” in der Adresszeile zwar nicht an, wenn man die URL aber aus der Adresszeile rauskopiert und wo anders einfügt, ist der “/” dran.

Eigeben Return drücken:

Screenshot from 2024-07-26 09-09-23

Doppelklick in die URL Zeile

Screenshot from 2024-07-26 09-10-09

Es wid nie der trailing “/” angezeigt - Selbst wenn du ihn eingibst ist er weg.

Chrome Stable 123.0.6312.105-1 auf Debian/Bookworm.

Wenn du es kopierst ist es da.

Flo

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.