Évolution des hyperliens sur LinuxFr.org

Posté par Benoît Sibaud (site web personnel) le 27 septembre 2018 à 14:15. Édité par Davy Defaud, BAud, Nils Ratusznik et dovik. Modéré par ZeroHeure. Licence CC By‑SA.

Étiquettes :

sept.

2018

Un matin, une question existentielle a fait jour dans mon esprit, comme ça, venue d’on ne sait où. Probablement dans le même genre que l’envie de Google de virer le « www. » dans les URL — même si www.example.com et example.com ne sont pas forcément équivalents, ou ses autres envies de virer carrément les URL ou HPKP.

Bref, je me demandais « quels sont les schémas d’URI (scheme) et les domaines les plus utilisés par les visiteurs de LinuxFr.org dans les contenus et commentaires, et est‐ce que (plutôt comment) ça a changé au fil des années ? ».

Évidemment, ça ne donnera un état et une évolution que sur les visiteurs du site, et pas sur Internet en général (même si certains ne connaissent d’Internet que leur réseau social préféré, mais ceux‐là ne nous intéressent pas ici, car soit ils ne viennent donc pas sur LinuxFr.org, soit ils y sont en permanence mais ne mettent pas de liens pour en sortir vu qu’ils n’en sortent pas).

N. B. : Étonnamment, cette question a été jugée prioritaire par votre serviteur par rapport à la dépêche « Statistiques 2017 du site LinuxFr.org (2/2) » qui se bonifie en rédaction depuis le 7 janvier…

C’est plus compliqué que prévu

Évidemment, ça ne serait pas drôle si c’était facile et rapide. De migrations en migrations, certains contenus et commentaires du site ne sont pas en HTML valides ou ne sont pas bien formés. Donc, on va attaquer les données un peu sauvagement à coups d’expressions rationnelles, ce qui n’est pas idéal pour analyser. Et, bien évidemment, on a :

des contenus et commentaires qui comportent du code ou des commandes shell type sed -e "s/^$3://" ;
des extraits verbatim de journaux système (dont des URL pourries de journaux de serveurs Web) qui compliquent un peu plus le job ;
de l’ASCII art du type ¯\_(ツ)_/¯ ;
des nommages du type ht://Dig ;
des gens qui, comme moi, ont écrit dans du texte http(s)://linuxfr.org ;
des contenus et commentaires erronés (ce qui a permis quelques corrections au passage) : par exemple des liens de type :
- http://example.invalidhttp://example.invalid (double URL),
- http://https://example.invalid ou http://ftp://example.invalid (double schéma),
- http%20://example.invalid (espace excédentaire),
- http:/example.invalid (barre oblique manquante),
- news://example.invalid, mailto://example@example.invalid ou xmpp://example@example.invalid (deux barres obliques excédentaires),
- htttp://example.invalid ou htpp://example.invalid ou htt://example.invalid ou http:example.invalid (mauvais schéma),
- absence de schéma example.invalid,
- oui, ces exemples ne sont pas gentils pour le prochain qui refera cette analyse, mon moi du futur m’en veut déjà ;
des dizaines de corrections suite à une erreur dans le script de conversion des contenus lors d’une migration technique du site, qui a converti des liens invalides <a href=http://example.com>example</a> (guillemets manquants) en invalides et inutiles <a href="http:" />example</a> (lien cassé, balise fermante) ;
une poignée de corrections sur des liens manquants <a href=""> ;
et il ne s’agit pas forcément de liens actifs ou cliquables (ça peut être du code, du texte verbatim, une partie commentée, etc.).

Bref, un rappel de pourquoi ça serait mieux d’avoir des pages valides et propres tout le temps.

Les dépêches

Dans le contenu des dépêches (les premières en base datant de mars 1999) :

du côté des schémas :
- 1999 : uniquement http ou ftp,
- 2000 : les premiers https (feu https://qa.mandrakesoft.com), php et ldaps pour les schémas,
- 2002 : les premiers pop, imap, news, mms et smb,
- 2003 : les premiers about et irc,
- 2004 : les premiers ldap et sftp,
- 2005 : les premiers pnm, tivo et udp,
- 2006 : les premiers svn et svn+ssh,
- 2007 : les premiers file, lastfm et xmpp,
- 2008 : les premiers git, itms et silc,
- 2009 : rien de neuf,
- 2010 : le premier apt, et les parodiques dis et goo (pour Disney/Google),
- 2011 : rien de neuf,
- 2012 : le premier spdy,
- 2013 : rien de neuf,
- 2014 : les premiers auth, bhyve, gobby et proxy,
- 2015 : les premiers chrome, et, ircs et unv,
- 2016 : les premiers amqp, appstream, influxdb-timed-mydata, mongodb-timed-mydata, protocol-datatype-datascope et wss (et aussi le livre de T. Nitot surveillance://),
- 2017 : les premiers tcp et ldapi,
- 2018 : au moins les premiers dat, ipfs et ssb ;
du côté des noms les plus présents (qui peuvent être libristes ou non, et la quantité n’est pas forcément le meilleur indicateur pour juger de la qualité) :
- 1999 : www.linux-gull.ch, www.freepatents.org, (feu) www.ude.org, www.slashdot.org, (feu) www.linux-mandrake.com, www.xfree86.org, updates.redhat.com, support.free.fr, altern.org et x42.com,
- 2000 : mail.gnome.org, www.kde.org, (feu) petition.eurolinux.org, dri.sourceforge.net, www.parinux.org, www.opencascade.com, www.linux-arverne.org (GULL co-fondé par votre serviteur et qui a perdu son tiret depuis) et www.altavista.com,
- 2001 : (feu) infonomade.linuxfr.org, lists.debian.org, www.debian.org, packages.debian.org, slashdot.org, www.transfert.net, (feu) www.linux-mandrake.com, www.gnu.org et fr.news.yahoo.com,
- 2002 : www.fosdem.org, www.google.com, www.gnu.org, www.debian.org, www.april.org, slashdot.org, (feu) petition.eurolinux.org, www.mozilla.org et www.gphoto.org,
- 2003 : artlibre.org, www.april.org, slashdot.org, www.mozilla.org, sourceforge.net, eucd.info, creativecommons.org, fr.wikipedia.org et www.python.org,
- 2004 : www.mozilla.org, www.eyrolles.com, fr.openoffice.org, www.gnome.org, ftp.mozilla.org, sourceforge.net, www.redhat.com, www.openbsd.org et mail.gnome.org,
- 2005 : fr.wikipedia.org, en.wikipedia.org, lwn.net, eucd.info, sourceforge.net, wiki.ubuntu-fr.org, www.gnome.org, dev.mysql.com et www.mozilla.org,
- 2006 : fr.wikipedia.org, en.wikipedia.org, www.toulibre.org, free-electrons.com, lwn.net, www.aldil.org, sourceforge.net, www.debian.org et www.apitux.org,
- 2007 : fr.wikipedia.org, en.wikipedia.org, lwn.net, www.april.org, www.toulibre.org, www.candidats.fr, www.agendadulibre.org, sourceforge.net et maps.google.fr,
- 2008 : fr.wikipedia.org, en.wikipedia.org, lwn.net, www.agendadulibre.org, www.toulibre.org, www.openbsd.org, www.april.org, git.kernel.org, www.laquadrature.net,
- 2009 : fr.wikipedia.org, en.wikipedia.org, www.zdnet.fr, www.april.org, lwn.net, www.pcinpact.com (devenu nextinpact.com), git.kernel.org, www.openbsd.org et www.silicon.fr,
- 2010 : fr.wikipedia.org, www.numerama.com, www.pcinpact.com, en.wikipedia.org, www.zdnet.fr, www.april.org, git.kernel.org, github.com et lwn.net,
- 2011 : fr.wikipedia.org, en.wikipedia.org, git.kernel.org, github.com, www.numerama.com, www.april.org, lwn.net, weboob.org et owni.fr,
- 2012 : fr.wikipedia.org, en.wikipedia.org, github.com, git.kernel.org, www.pcinpact.com, www.april.org, www.numerama.com, netbsd.gw.com et lwn.net,
- 2013 : fr.wikipedia.org, github.com, en.wikipedia.org, www.pcinpact.com, www.april.org, www.framablog.org, www.zdnet.fr, www.numerama.com et illwieckz.net,
- 2014 : fr.wikipedia.org, github.com, git.kernel.org, en.wikipedia.org, www.nextinpact.com, www.numerama.com, www.april.org, www.nsa-observer.net et www.openstreetmap.org,
- 2015 : www.agendadulibre.org, fr.wikipedia.org, github.com, web.nvd.nist.gov, www.april.org, git.kernel.org, www.nextinpact.com, en.wikipedia.org et pix.toile-libre.org,
- 2016 : www.agendadulibre.org, www.agendadulibre.qc.ca, github.com, montpel-libre.fr, www.nextinpact.com, en.wikipedia.org, www.april.org et www.zdnet.fr,
- 2017 : www.agendadulibre.org, agendadulibre.qc.ca, fr.wikipedia.org, montpel-libre.fr, github.com, www.meetup.com, www.agendadulibre.ch, linuxmao.org et www.gnu.org,
- 2018 (partielle) : www.agendadulibre.org, agendadulibre.qc.ca, fr.wikipedia.org, montpel-libre.fr, linuxmao.org, github.com, gmic.eu et wiki.parinux.org et librazik.tuxfamily.org.

On notera les problématiques majeures (brevets logiciels, puis EUCD), les distributions les plus mentionnées de chaque époque, la montée de Wikipédia ou OpenStreetMap, etc.

En se limitant aux liens des dépêches (ceux avec les compteurs de visites), côté schémas : le tout‐Web progresse (en partie parce que le site lui‐même restreint les choix), avec remplacement http par https, et sinon disparition peu à peu du ftp et du mailto (merci le spam) et d’un peu tout le reste.

année	https://	http://	ftp://	mailto:
1999	0,00 %	94,08 %	4,28 %	1,63 %
2000	0,14 %	96,52 %	2,37 %	0,97 %
2001	0,25 %	96,81 %	2,57 %	0,37 %
2002	1,02 %	97,40 %	1,49 %	0,10 %
2003	0,96 %	98,10 %	0,79 %	0,15 %
2004	0,69 %	98,83 %	0,39 %	0,09 %
2005	1,34 %	98,31 %	0,35 %	0,00 %
2006	1,79 %	97,99 %	0,19 %	0,03 %
2007	1,14 %	98,66 %	0,15 %	0,05 %
2008	2,95 %	96,97 %	0,08 %	0,00 %
2009	2,35 %	97,47 %	0,18 %	0,00 %
2010	4,00 %	95,85 %	0,13 %	0,03 %
2011	9,28 %	90,63 %	0,08 %	0,00 %
2012	12,12 %	87,79 %	0,09 %	0,00 %
2013	16,87 %	83,05 %	0,08 %	0,00 %
2014	24,05 %	75,95 %	0,00 %	0,00 %
2015	31,82 %	68,05 %	0,07 %	0,07 %
2016	44,30 %	55,63 %	0,08 %	0,00 %
2017	55,20 %	44,80 %	0,00 %	0,00 %
2018	77,17 %	22,75 %	0,00 %	0,08 %

(en omettant 1 gopher://, 1 git://, 1 rsync://, 2 xmpp:, 4 rtsp://, 6 news:, 7 nntp:// et 11 irc://)

Les liens

Nouveau contenu du site apparu en 2018, les liens ne sont pas forcément encore très représentatifs (seulement 238 au moment de calculer ces statistiques, avec 34 http et 204 https). Les noms les plus présents sont : www.nextinpact.com, www.dsfc.net, www.developpez.com, github.com, www.lemonde.fr, www.gimp.org, framasphere.org et www.youtube.com.

# www ou non

Posté par Wawet76 le 27 septembre 2018 à 14:51. Évalué à 4.

En lisant le début de la dépêche, je m'attendais à voir l'évolution des liens http et https qui commencent par www (https://www.example.invalid), autre chose (https://wiki.example.invalid), ou rien (https://example.invalid)

Perso j'aime bien quand y'a rien, mais l'absence de CNAME possible empêche (ou complique fortement en tout cas) des choses comme l'utilisation d'un CDN. Du coup je me demande si ce n'est pas mieux de mettre le classique www au cas où.
- [^] # Re: www ou non
  
  Posté par Thomas Debesse (site web personnel) le 27 septembre 2018 à 23:20. Évalué à 4.
  rajouter le www demande un certificat supplémentaire (ou une entrée supplémentaire dans le certificat) et ne fonctionnera pas avec un wildcard.
  
  imagine que tu as un domaine example.com pour une collectivité territoriale, et un sous-domaine par commune, tu aurais donc
```
example.com
issy-oula.example.com
canne-apeche.example.com
lyon-sceaux.example.com
```
  si tu veux ajouter les www tu peux faire les certificats suivants:
```
example.com
issy-oula.example.com
www.issy-oula.example.com
canne-apeche.example.com
www.canne-apeche.example.com
lyon-sceaux.example.com
www.lyon-sceaux.example.com
```
  ou bien :
```
example.com
issy-oula.example.com www.issy-oula.example.com
canne-apeche.example.com www.canne-apeche.example.com
lyon-sceaux.example.com www.lyon-sceaux.example.com
```
  ou bien :
```
*.example.com example.com
www.issy-oula.example.com
www.canne-apeche.example.com
www.lyon-sceaux.example.com
```
  ou bien :
```
*.example.com example.com www.issy-oula.example.com www.canne-apeche.example.com www.lyon-sceaux.example.com
```
  et plein d’autres variations alors qu’il suffirait de faire un seul certificat :
```
*.example.com example.com
```
  j’ai ce cas précis dans mon boulot, c’est pas une communauté de commune mais c’est territorial et il y a plus de 200 domaines. Je peux dire que j’ai défendu mon bout de gras les dernières fois que quelqu’un de la comm' a pensé qu’il serait plus branché d’écrire un www sur une plaquette imprimée à plusieurs milliers d’exemplaires. Et plus personne ne le fais, ouf, mais il faut garder historiquement une petite dizaine de www à cause de ça…
  
  La nécessité du www en début d’url relève limite de la légende urbaine, et est un parfait exemple de Culte du cargo dans le domaine informatique. Mettre un www au début d’une url n’a aucun sens et n’en a jamais eu^*.
  
  ^* Je mets une astérisque parce que peut-être qu’un jour ça a eu sens pour quelqu’un. Le www au début d’une url c’est un peu comme si M. Dupont habitant au 4 avenue des narcisses à Bormes-les-hortensias voit que M. Dupuis écrit son adresse ainsi sur sa carte de visite « lieu-dit des sources, 378 chemin des roseaux, Laÿ-les-gentiannes » et écrirait donc sur sa carte de visite « lieu-dit des sources, 4 avenue des narcisses, Bormes-les-hortensias » et que 40 ans après la moitié de la population préfixait son adresse avec « lieu-dit des sources » sans savoir pourquoi, et que la moitié des autres recommandait tout de même de préfixer son adresse ainsi parce que ça permet de mettre un écriteau « les sources » devant sa maison alors que sinon on ne pourrait pas, et les derniers ne se demanderaient même pas à quoi servirait de pouvoir placer ledit écriteau devant sa maison.
  
  L’argument présenté du CDN et du CNAME est peut-être un des rares cas qui se tient vite-fait, mais à vrai dire le concept de CDN vient pallier l’absence de protocole adapté à ce besoin (par exemple des fonctionnalités de multicast, de P2P etc. changerait sérieusement la donne et serait beaucoup plus propre).
  
  ce commentaire est sous licence cc by 4 et précédentes
  - [^] # Re: www ou non
    
    Posté par PLuG le 28 septembre 2018 à 19:28. Évalué à 8. Dernière modification le 29 septembre 2018 à 07:59.
    
    il y a fort longtemps, on utilisait de façon très basique le DNS.
    example.com c'était le nom de domaine, il ne portait pas d'adresse IP.
    www c'était l'entrée DNS qui portait l'adresse IP du serveur web sur le port 80.
    ftp c'était l'entrée DNS qui portait l'adresse IP du serveur ftp.
    du coup www.example.com visait une machine en particulier, ftp.example.com potentiellement une autre.
    A l'époque, pas de certificats, et personne ne parlait du préfixe qui fixe le protocole (http:// ou ftp://)
    d'ailleurs ftp:// n'existait pas, avec le navigateur on faisait du www (World Wide Web) sinon on prenait un client ftp :-)
    
    Bon c'est caduque, et sur les imprimés grand public on peut écrire https://example.com même madame michu s'y est habituée.
  - [^] # Re: www ou non
    
    Posté par kowalsky le 01 octobre 2018 à 10:14. Évalué à 2.
    
    Je ne comprend pas ton souci ?
    
    Il suffit d'utiliser un certificat avec du SAN, deux entrées par domain name :
    
    SAN : domain1.com,*.domain1.com,domain2.com,*.domain2.com
    
    Ou je n'ai pas compris ton besoin…
    - [^] # Re: www ou non
      
      Posté par Thomas Debesse (site web personnel) le 01 octobre 2018 à 17:36. Évalué à 5.
      C’est bien justement ça le problème : devoir gérer les www sur des sous-domaine implique de déclarer tous les sous-domaines.
      
      Je parle bien de ce schéma là :
      
      ville.fr paris.ville.fr lille.ville.fr nice.ville.fr marseille.ville.fr strasbourg.ville.fr
      
      Pour gérer le www de chacun de ces sous-domaines (pour faire www.nice.ville.fr par exemple) il faut déclarer tous ces sous-domaines, SAN est juste un moyen de réduire le nombre de certificats, pas un moyen de ne pas déclarer explicitement ces sous-domaines.
      
      Maintenant tu mets Letsencrypt dans la boucle, avec des certificats que tu renouvelles tous les trois mois, bah t’es coincé. Tu as 300 sites en ville.fr ? Tu veux aussi gérer les www ? tu dois faire valider 600 domaines dans la semaine alors que tu ne peux qu’en valider 20 par semaines ? Tu ne t’en sors que grâce au SAN justement.
      
      Je rappelle les contraintes de Letsencrypt:
      
      100 domaines maximum par certificat
      
      20 certificats par semaine pour un même domaine principal (pour example.com tu peux demander vingt fois quelquechose.example.com, pas plus)
      
      5 erreurs par semaine
      
      J’ai justement mis en place une infrastructure qui découpe des listes de domaines pour faire des certificats Letsencrypt par paquet de 100 domaines. Je peux donc théoriquement faire certifier 1999 sous-domaine plus d’un même domaine principal par semaine, plus ce domaine principal.
      
      Letsencrypt a rendu possible la création de certificats wildcard depuis que j’ai mis en place cette infrastructure, et je compte bien y passer un jour, mais le wildcard ne prendra pas en charge les www.
      
      Actuellement je certifie 300 domaines avec 3 paquets de 100. Si je devais certifier les www je devrais certifier 600 domaines avec 6 paquets de 100.
      Quand je serai passé au wildcard letsencrypt je certifierai 300 domaines avec 1 paquet de 2 (example.com et *.example.com), je ne veux surtout pas devoir certifier 300 www ni 300 wildcard supplémentaires juste parce qu’ « on a toujours fait ainsi »…
      
      Le préfixe www a un coût humain, logistique et économique non négligeable.
      
      En mettre un devrait être une exception qui doit répondre à un besoin technique très particulier, avec lettre de motivation en trois exemplaires, tampon du directeur, du comptable, des ressources humaines, de l’avocat et une signature du BOFH en lettres de sang.
      
      Je veux bien entendre que dans certains cas le www puisse répondre techniquement à une problématique matérielle évident, mais en mettre un parce que le service comm' trouve ça web 4.0, non. Quand on voit un www il faut penser « tiens ces gens semblent faire face à des problématiques techniques d’une matérialité évidente ». Si t’es pas un des dix plus gros acteurs du ouaibe ça devrait être mauvais pour ton image de mettre un www.
      
      ce commentaire est sous licence cc by 4 et précédentes
      - [^] # Re: www ou non
        
        Posté par kowalsky le 02 octobre 2018 à 11:54. Évalué à 3.
        
        OK je comprend le problème maintenant.
        
        Quand je prend un certificat, je prend toujours le domaine et le wildcard, c'est plus simple.
        
        Dans ton exemple, même sans le www, si une ville à besoin de voirie.nantes.ville.fr, par exemple, c'est faisable.
  - [^] # Re: www ou non
    
    Posté par benoar le 01 octobre 2018 à 13:53. Évalué à 4.
    
    L’argument présenté du CDN et du CNAME est peut-être un des rares cas qui se tient vite-fait, mais à vrai dire le concept de CDN vient pallier l’absence de protocole adapté à ce besoin (par exemple des fonctionnalités de multicast, de P2P etc. changerait sérieusement la donne et serait beaucoup plus propre).
    
    La bonne solution sans réinventer un protocole c'est de pousser à l'adoption des enregistrements SRV, qui peuvent servir aux usages pour lequel on fait habituellement du CDN tout comme d'autres choses (failover, serveur de backup, etc) : https://bugzilla.mozilla.org/show_bug.cgi?id=14328
    Mais pour ça il va falloir se battre avec le code source de Firefox et la bureaucratie de Mozilla, appuyée par Google.
    
    Et comme ça, on n'aura plus besoin de www tout en ayant bien mieux niveau fonctionnalités que ce palliatif.
    - [^] # Re: www ou non
      
      Posté par Thomas Debesse (site web personnel) le 01 octobre 2018 à 17:38. Évalué à 2.
      
      Très bonne idée ! Et puis c’est transparent pour l’utilisateur, pas comme le www. :-)
      
      ce commentaire est sous licence cc by 4 et précédentes
    - [^] # Re: www ou non
      
      Posté par sizvix (site web personnel) le 02 octobre 2018 à 17:07. Évalué à 1.
      
      Ha ouai, " Reported: 19 years ago "
      C'est pas une idée récente ^{^U}
      
      Essaie pour vivre sans brider les utilisateurs https://www.indiegogo.com/projects/iwinote
      - [^] # Re: www ou non
        
        Posté par benoar le 03 octobre 2018 à 16:43. Évalué à 4.
        
        Oui, le combat est politique : sans cette feature, il est difficile de s'héberger correctement (complexité de la gestion de TLS, complexité sur failover sans CDN, etc) avec des moyens raisonnables, sans être un « gros ». Étrangement, parmi ceux qui s'opposent dans ce rapport de bug à la résolution de ce problème par des entrées SRV avec des arguments plus ou moins valable, on trouve des ingénieurs de chez Google. Et Google finance Mozilla. Forcément, ça doit donner envie de laisser traîner la résolution…
- [^] # Re: www ou non
  
  Posté par sizvix (site web personnel) le 29 septembre 2018 à 13:26. Évalué à 6. Dernière modification le 29 septembre 2018 à 15:40.
  
  Nous, on a l'habitude de différencier les ***.ndd.xx , et www.ndd.xx est l'accueil basique.
  Le ndd.xx brut accueil l'entreprise et les différents services, et bien souvent les utilisateurs cherchent et vont vers le www.ndd.xx
  
  Pour le fait de perdre les URLs , je trouve ça une aberration où tu deviens dépendant de ton "navigateur" ou autre outils que tu utilises ( notamment le moteur de recherche qui te propose les pages correspondants à ce que tu demandes )
  Pour ma part, je fais de la sensibilisation au URLs autour de moi pour que les gens restent maître de leur navigation et ne se trouvent pas dépendant de leur moteur de recherche.
  Et pour moi, une information sur httpS://www.edf.fr est plus sûr qu'une lettre dans la boite aux lettres avec n'importe quel numéro de compte indiqué pour le virement …
  
  Essaie pour vivre sans brider les utilisateurs https://www.indiegogo.com/projects/iwinote

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.