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

Communities Deutschland (Germany)
1

Hi,
hier ist jemand dabei und fügt an alle URIs die kein “/” am ende haben eines an. Ich halte das für ziemlichen Unsinn - Ich hab jetzt mehrfach nachgefragt ob er diesen mechanischen Edit irgendwo im Forum mal diskutiert hat - ich kenne die Diskussion nicht.

Deshalb hier:

Mechanischer edit - Bei allen URIs die das format “http(s)://domain.ain” haben ein “/” anfügen?

Technisch ist das nicht nötig. Der Browser muss im HTTP request ein “/” requesten allerdings macht er das ja auch ohne das wir ein explizites “/” angeben.

Werbebotschaften, Abgedruckte URIs enthalten typischerweise das “/” nicht.

Flo
PS: Changeset diskussion: Changeset: 154196378 | OpenStreetMap

6 Likes
2

Note that in some cases adding / at the end of link causes link to stop working or change page content.

Any such edit needs to check whether “fixed” links lead to the same page, even if such edit make sense in the first place.

Note that you can revert, without discussion, any automated edits done without discussion.

4 Likes
3

Falls @localhorst tatsächlich jede Änderung manuell durchführt (und dabei prüft, dass die URL existiert/zum gleichen Ziel führt und im besten Fall auch noch aktuell ist), wäre es kein mechanischer Edit und mMn vollkommen OK. Da die CS jeweils nur wenige Änderungen enthalten, halte ich das auch nicht für unplausibel. Aber wäre natürlich gut, wenn er kurz die “Methodik” erläutert wenn es Zweifel daran gibt.

P.S. Ob das notwendige/sinnvolle Edits sind, steht aber auf einem anderen Blatt.

4 Likes
4

:+1:
Sehe ich auch so.

4 Likes
5

Will da jemand auf billige Art und Weise seine Statistik frisieren ?

6

Ich kenne wenigstens eine weit verbreitete Software, die das unterscheidet und damit nicht klarkäme.
Darüber hinaus gibt es zahlreiche manuell gebastelte Umleitungsregeln, die auch nur mit dem getestet werden, was man selber mal öffentlich verlinkt hatte, und nicht mit Alternativen, so “zulässig” sie auch sein mögen.

1 Like
7

Wir können uns dem ganzen erstmal technisch nähern - RFC3986 - Uniform Resource Identifier (URI): Generic Syntax

https://www.rfc-editor.org/rfc/rfc3986.html#section-3.3

path = path-abempty ; begins with “/” or is empty
/ path-absolute ; begins with “/” but not “//”
/ path-noscheme ; begins with a non-colon segment
/ path-rootless ; begins with a segment
/ path-empty ; zero characters

D.h. es ist völlig legitim das der “path” leer ist - Also “Zero characters”.

D.h. nach RFC (Request for Comment - Standards des Internets) ist es nicht notwendig den “/” als path zu haben in einer URI (Uniform Resource Identifier).

Und URIs sind das was wir bei OSM Abbilden.

Die Argumentation des mappers ist das wenn die URI von einem Browser requested wird in dem HTTP Request ja ein “/” requested werden MUSS. Das ist auch richtig.
Wir nehmen mal das RFC für HTTP/1.0 - nachfolgende haben IIRC an dem / nichts geändert - RFC1945 Hypertext Transfer Protocol – HTTP/1.0

https://datatracker.ietf.org/doc/html/rfc1945#section-5.1

Note that the absolute path cannot be empty; if none is present in the original URI, it must be given as “/” (the server root).

D.h. wenn der Browser die URI nimmt und dann bei einem Webserver da einen Request absetzt wird aus dem leeren Path in der URI ein “/” weil es im Protokoll nicht vorgesehen ist das der “path” leer ist. Das macht der Browser für dich.

Das wir deshalb aber weil es im Protokoll (nicht in der Repräsentation der location eines Objektes) ein “/” vorgeschrieben ist an alle URIs ein “/” anhängen ist völliger Unsinn.

Und für den Webserver ist die URI “http://www.dom.ain” überhaupt nicht sichtbar in dieser Repräsentation - Das wird zu so einem Request: (HTTP/1.1)

GET / HTTP/1.1
Host: www.dom.ain

draus - Egal ob du in der URI ein “/” am ende hast oder eben nicht.

RICHTIG ist - wenn du einen path hast d.h.

http://www.dom.ain/path

ist das was anderes als

http://www.dom.ain/path/

Wieder der HTTP Request:

GET /path HTTP/1.1
Host: www.dom.ain

vs.

GET /path/ HTTP/1.1
Host: www.dom.ain

Wie man hier sieht wird das “/” eben nicht drangedichtet sondern nur dann mitgesendet wenn es auch in der URI drin war - aber NUR dann wenn es einen path gibt. Und dann kann natürlich der Webserver - z.b. ein Apache anders reagieren. Ohne Pfad gibt es auf Webserver seite keine unterscheidung.

Also - bei URIs ohne path Bestandteil ist der trailing / überflüssig und nach Standard nicht required - ausserdem macht es keinen unterschied im HTTP request.

Flo

2 Likes
8

Alle Edits sind händisch gemacht Natürlich prüfe ich die URLs, ob sie erreichbar sind. Außerdem gleiche ich sie noch mit Wikipedia ab. Wenn URLs nicht erreichbar sind oder sich von denen bei Wikipedia unterscheiden (bis auf den fehlenden “/” für das Wurzelverzeichnis), werden sie von mir komplett manuell geprüft und versucht, die richtige/aktuelle URL herauszufinden.

Das OSM-Wiki (https://wiki.openstreetmap.org/wiki/DE:Key:website) sagt:

Formatierung

Webseiten URLs haben gewöhnlicherweise folgende Schreibweise :
http(s)://(www.)domain.tld/(page)(?parameters)(#anchor), die Teile in Kammern können optional sein.

Da ist der “/” für das Wurzelverzeichnis nicht optional, sondern fester Bestandteil der URL.

RFC 3986 sagt im Abschnitt 6.2.3. (https://datatracker.ietf.org/doc/html/rfc3986#section-6.2.3):

In general, a URI that uses the generic syntax for authority with an empty path should be normalized to a path of “/”.

9

Du unterschlägst halt den Grund für die mögliche Normalisierung - Es geht hier um “equivalence” im technischen Sinne wenn es z.b. um einen Cache index geht. Bei OSM ist es ein link - kein technischer primary key in einen Cache - D.h. die normalisierung ist hier überhaupt nicht nötig. Dazu alle anderen Gründe der möglichen normalisierung treffen hier alle nicht zu.

Dazu unterschlägst du im selben Absatz wie von dir Zitiert:

For example, because the “http” scheme makes use of an authority
component, has a default port of “80”, and defines an empty path to
be equivalent to “/”, the following four URIs are equivalent:

  http://example.com
  http://example.com/
  http://example.com:/
  http://example.com:80/

Und das mit dem SHOULD liest du dann nochmal im RFC 2119 - Key words for use in RFCs to Indicate Requirement Levels nach

3. SHOULD This word, or the adjective “RECOMMENDED”, mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

Da diese Equivalent sind musst du hier schon erklären warum das sein MUSS.

Es gibt überhaupt keinen Grund hier so einen Noise in der Datenbank zu machen und URIs zu ändern die Mapper von Webseiten, Visitenkarten etc exakt so übernommen haben - die du jetzt für NIX zu etwas anderem änderst das equivalent ist.

Flo

2 Likes
10

Und das hab ich im übrigen oben wiederlegt - Wenn du die BNF im RFC3986 liest. Sagt eben das RFC.

Ich zitiere das aber nochmal:

https://datatracker.ietf.org/doc/html/rfc3986#section-3

 URI         = scheme ":" hier-part [ "?" query ] [ "#" fragment ]

  hier-part   = "//" authority path-abempty
              / path-absolute
              / path-rootless
              / path-empty

https://datatracker.ietf.org/doc/html/rfc3986#section-3.3

  path          = path-abempty    ; begins with "/" or is empty
                / path-absolute   ; begins with "/" but not "//"
                / path-noscheme   ; begins with a non-colon segment
                / path-rootless   ; begins with a segment
                / path-empty      ; zero characters

  path-abempty  = *( "/" segment )
  path-absolute = "/" [ segment-nz *( "/" segment ) ]
  path-noscheme = segment-nz-nc *( "/" segment )
  path-rootless = segment-nz *( "/" segment )
  path-empty    = 0<pchar>

Man beachte “path-empty” - Im hier-part explizit erwähnt.

Valide URI ohne “/”

Flo

1 Like
11

Was willst du widerlegt haben? Ich beziehe mich dabei auf das OSM-Wiki und dort ist der “/” für das Wurzelverzeichnis eben nicht als optional markiert.

12

Das stimmt, allerdings steht dort auch “usually”.

Websites URL usually follow this syntax:

Planst Du die Änderung Deutschlandweit zu machen?

2 Likes
13

Es gibt gute Gründe, URLs zu normalisieren.

Technische Korrektheit und Eindeutigkeit:

  • Der abschließende Schrägstrich macht unmissverständlich klar, dass es sich um die Wurzel der Domain handelt.

Konsistenz:

  • Die Normalisierung schafft ein einheitliches Format für alle URLs, was die Verarbeitung und den Vergleich erleichtert.
14

Wo ist da der Unterschied zu der URI ohne abschließenden Schrägstrich? Ich seh da keinen.

15

Ich plane, deutschlandweit die URLs von Städten, Gemeinden, Landkreisen etc. zu korrigieren, inklusive nicht mehr erreichbarer URLs, URLs die mittlerweile von http zu https migriert sind 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, wo es nicht anders geht (Beispiele sind Verwaltungsgemeinschaften, bei denen nicht jede Gemeinde eine eigene Domain hat und es auf der Verbandswebsite Unterseiten für die Gemeinden gibt). Dazu gehört für mich auch die Korrektur des fehlenden Root-“/”, um eine einheitliche Konsistenz herzustellen.

1 Like
16

Aeh - nein - Mit der domain hat das gar nichts zu tun. “/” ist kein erlaubtes zeichen in domains/DNS.

Dein hostname ist zuende mit dem ende der URI oder einem “/” - Deshalb - siehe nochmal BNF darf das auch leer sein weil es keinen unterschied macht.

Du wirfst hier glaube ich zig sachen durcheinander.

Flo

2 Likes
17

Ganz so schlimm ist es nicht, nur unsauber formuliert.
Es ist so was wie “Wurzel des paths nach der domain” gemeint.

Das Überprüfen der URI ist eine sehr lobenswerte Sache, das Anfügen des “/” aber ist überflüssig.

3 Likes
18

Ich halte das für eine schlechte Idee.

Redirects können z.B. aufgrund von Browser/User-Agent, Geräteklassen, Language oder GeoIP erfolgen. Vermutlich 1000 andere Sachen.

Für mich ist die korrekte URL und Domain das, was an einer Einrichtung draussen dransteht, oder wenigstens auf Speisekarten, Visitenkarten etc. , ich halte es für destruktiv, irgendwelche Redirects auszuwerten und deren Resultat wegzubuchen.

Wenn ein Laden seine Adresse als http:// und mit-oder-ohne-www-davor angibt, dann ist das m.E. verbindlich.

4 Likes
19

Als Fachfremder verstehe ich diesen Punkt noch nicht ganz. Du schreibst “technische Korrektheit”. Macht es technisch einen Unterschied ob der Schrägstrich vorhanden ist? Ist es technisch möglich dass die beiden Varianten zu unterschiedlichen Webseiten führen, z.B. durch unterschiedliche Weiterleitungen?

20

Nein, siehe

somit ist das Anhängen des Schrägstriches am Ende der Domain überflüssig, deswegen sehe ich das wie @seichter

4 Likes