4 comments on “URLs (Netzwerkgrundlagen) – Anwendungsentwickler-Podcast #136”

1. Marcel sagt:

   21. Mai 2019 um 10:36:38 Uhr

   Hallo Stefan,

   hast Du einer verlässliche Quelle, woher die 81% PHP Marktanteile kommen, die man selber nachvollziehen kann?
   Würde mich sehr als Argumentgrundlage interessieren, da ich oft Zahlen hören und gefragt werden, wo ich diese her habe und wie die zustande kommen.

   GGDVG

2. Stefan Macke sagt:

   21. Mai 2019 um 11:06:10 Uhr

   Hallo Marcel, schau mal hier: https://w3techs.com/ Die werten 10 Millionen Websites aus und da ist PHP Anfang 2019 bei 79% Marktanteil. WordPress allein hat schon 30% Marktanteil aller Website.

3. Julian Schweinsberg sagt:

   21. Mai 2019 um 20:55:51 Uhr

   Ersteinmal:

   URLs sind eine tolle Sache: Sie sind einheitlich aufgebaut und die Liste der Protokolle ist erweiterbar.

   Zur „selben“ Zeit (Gopher: [September 1991][1], WWW: „Sommer 1991“) als der erste WWW-Browser kursierte (URLs sind effektiv mit dem WWW einhergegangen) sah es bei Gopher im Bezug auf Hyperlinks bzw. dem Referenzieren von „Dritt-Protokoll“-Ressourcen anders aus: Nach RFC 1436 gibt es 14 verschiedene Menüitemtypen, davon beziehen sich nur 3 auf andere Protokolle (zusätzlich: mindestens finger und HTTP 0.9 kann man theoretisch mittels Itemtyp „0“ abdecken). Im Vergleich zu Systemen die URLs benutzen „ein Witz“.

   (URLs sind mithilfe einer [Konvention][7] „neuerdings“ auch in Gopher benutzbar)

   Ich denke schon, dass der Hostname „www“ praktische Relevanz hat:

   Anders als bei einigen anderen Protokollen gibt es für HTTP keine spezifizierten SRV-Records im DNS. HTTP muss somit immer (wenn nicht anders in der URL angegeben) auf Port 80 auf dem Host laufen auf den der Domainname/Hostname aus der URL (eventuell über Umwege) im DNS zeigt.

   Wenn ich nun aus idiologischen oder sicherheitstechnischen Gründen meinen HTTP-Server nicht auf dem selben Host wie meinen Gopher-Server laufen lassen will, dann muss einer der beiden Server auf einen anderen Host ausweichen und benötigt einen anderen Hostnamen. Und da bieten sich die Hostnamen aus RFC 2219 (unteranderem „www“) an.

   Jetzt mal abgesehen von diesem Nicht-Grund, hier ein realistischer (mir ist im Nachhinein aufgefallen, dass das derselbe ist…):

   Wer sagt, dass ich nicht irgendwann einmal meinen HTTP-Server auf einen anderen Host umziehen werde, dessen Hostname dann von dem der Domain (da läuft dann nur mein Gopher-Server drauf :P) abweicht (verwirrend: Die „Domain“ kann Domainname und Hostname sein), dann werden alle alten Hyperlinks nicht mehr funktionieren.

   Aber frei nach dem Motto „Cool URIs don’t change“ wollen wir das nicht.

   Einfachste Lösung: Der Hostname „www“ zeigt im DNS via CNAME auf den momentanen Host mit HTTP-Server und man benutzt von Anfang an in allen Hyperlinks den „www“-Hostnamen. Diese Indirektion erlaubt es uns den HTTP-Server irgendwo anders hinzuschieben ohne andere Dienste zu beeinträchtigen. „www“ beschreibt somit nicht mehr den Hostnamen sondern den Verweis auf den HTTP-Server „an sich“. (Ein Ersatz für den nicht existierenden SRV-Record für HTTP minus der Portangabe und noch anderen Dingen)

   [1]: * gopher://cyber.dabamos.de/0/gopher/articles/Usenet_Gopher_Announcement.txt „10. September 1991 – Client und Server veröffentlicht“ (Valide gopher://-URLs werden mindestens in der Vorschau ignoriert und aus dem Inhalt entfernt)

   [7]: * gopher://gopher.quux.org/0/Archives/Mailing Lists/gopher/gopher.2002-02|/MBOX-MESSAGE/34

4. Stefan Macke sagt:

   21. Mai 2019 um 21:41:27 Uhr

   Hallo Julian, vielen Dank für die Ergänzung. Aber: Gopher!? Nutzt das (noch) jemand? 😀 Ansonsten finde ich die Idee mit dem DNS-Eintrag für „www“ gut, wenn man später den Server ändern will.

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    
    Markdown is turned off in code blocks:
     [This is not a link](http://example.com)

Here is some inline `code`.