Ein leerer path - also http://dom.ain/ ist identisch mit http://dom.ain - Das ist auf dem Webserver nicht unterscheidbar. Das ist protokollimmanent.
Flo
1 Like
Ich verstehe auch nicht, worin hier die Verbesserung liegen soll, wenn eine korrekte und zulässige Schreibweise in eine andere korrekte und zulässige Schreibweise geändert wird.
Gibt’s ein Beispiel für ein konkretes Problem, das dadurch gelöst wird?
2 Likes
Kann es nicht geben (s.o.).
Dann ist das also eher damit vergleichbar, ob man bei Telefonnummern Leerzeichen nach der Ortsvorwahl einfügt, wo dies nicht der Fall ist, richtig?
Das verbessert immerhin die Lesbarkeit. Ein Slash am Ende tut das nicht.
2 Likes
Nicht ganz.
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.
Telefonnummern werden von unterschiedlichen Programmen ausgewertet, da kann es vorkommen, dass auch mal Leerzeichen als unzulässig angesehen werden. Da war dem Programmierer die Einfachheit der Auswertung wichtiger als der Komfort für den Nutzer.
Was Ähnliches ist die Eingabe von Hausnummern. Da werden auch mal Zusätze wie 1a oder 17/1 abgelehnt, weil der Programmierer aus Nachlässigkeit nur Ziffern vorgesehen hat.
1 Like
Sollte man im Wiki vielleicht dokumentieren, dass beide Varianten (mit und ohne Schrägstrich) verwendet werden dürfen?
Ja bitte - Und gerne mit verweis auf der RFC zu URIs:
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
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
1 Like
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.
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:
Doppelklick in die URL Zeile
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
Genau das hat @localhorst auch geschrieben. 
Bei Firefox 128.0 (Linux Mint) übrigens das selbe Verhalten.
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.
7 Likes
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.
Viel kritischer als die Frage nach dem Slash fand ich auch eigentlich auch solche Themen aus der Ankündigung:
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.
4 Likes
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.
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.
Es ist unnötig, http manuell zu https zu ändern, wenn eine Migration des Webservers erfolgt ist.
Das macht schon der b-jazz-bot.
Ganz genau: / ist kein Muß.