URLs courtes : une implémentation open-source avec Symfony

Qu'est-ce qu'une "url courte" ou "short url" ?

Une "url courte" est, comme son nom l'indique, une chaîne de caractères représentant une url, composée d'un petit nombre de caractères, et pointant vers un document initialement situé à une adresse plus "longue".

Pour prendre un exemple dans l'actualité, l'url http://xav.cc/hadopi redirige vers le document situé à l'adresse http://fr.wikipedia.org/wiki/HADOPI (dont, par ailleurs, je recommande la lecture au plus grand nombre).

Exemples et intérêts

Appelées "short url" en anglais, les url courtes permettent tout simplement de disposer d'urls plus simples à manipuler pour pointer vers des documents. Cela présente plusieurs intérêts :

• l'envoi d'une url par email est plus simple avec une url courte. Cela peut également éviter les problèmes de cesure de fin de ligne dans les clients mails archaïques,
• ce type d'urls est plus adapté dans toutes les situations ou le nombre de caractères utilisable est limité :
  • les outils de microblogging, comme Identi.ca ou Twitter, par exemple, qui limitent à 140 le nombre de caractères des statuts que leurs utilisateurs peuvent envoyer,
  • les signatures d'email,
  • les sujets de canaux IRC,
  • etc.

Mécanismes

Il existe de très nombreux services fournisseurs d'url courtes : TinyURL est le plus ancien d'entre eux, mais la fonctionnalité est assez simple à copier et depuis de très nombreux services similaires ont vu le jour. Techniquement, la plateforme qui héberge l'url courte effectue une redirection vers l'url d'origine. Le code HTTP habituellement employé - en tout cas, celui qui devrait l'être - est le code 301.

Une page Web HTML peut déclarer son url courte préférée dans ses en-têtes, en employant la balise link pour l'attribut rel=shortlink :

<link rel="shortlink" href="http://xav.cc/hadopi" />

Le service de redirection de base est parfois complété par d'autres options :

• mise à disposition d'une API permettant l'emploi du service de manière programmatique, depuis des applications extérieures (extension du navigateur, site web, client riche, etc)
• réduction d'urls en masse
• pages intermédiaires permettant de connaître la destination de la redirection
• compteur de redirections

Ce schéma décrit deux mécanismes :

• en bleu : lorsque l'internaute souhaite accéder à une page par le biais d'une url courte, il fait appel au service d'origine qui effectue ensuite une redirection vers l'url initiale
• en vert : lorsque le client souhaite générer une url courte pour un document donné, que ce soit directement par le biais du site web du service ou par le biais d"une application intermédiaire (client Twitter par exemple), le service DEVRAIT découvrir l'url courte préférée du document. Ce qui signifie :
  1. charger le document donné
  2. regarder la valeur du header HTTP dédié à la présentation des urls courtes. Par exemple, Link: <http://domain.tld/shortlink>; rel=shortlink
  3. S'il n'y en a pas et que le document est un document HTML, chercher dans ses en-têtes HTML le lien alternatif d'url courte.
  4. Et alors, uniquement si aucune url courte préférentielle n'a été découverte pour ce document, générer une url courte te l'envoyer au client. Sinon, renvoyer l'url courte préférentielle découverte lors du chargement du document.

L'ensemble de ce procédé est parfaitement décrit dans la section "short URL" du wiki de snaplog.

Limitations et critiques

Si les systèmes de réduction d'url apportent de vrais avantages, ils sont néanmoins sujets à certaines critiques, pour des raisons variées.

Tout d'abord, tous ces systèmes sont de par leur nature sujets au link rot : comme c'est l'url courte qui est diffusée à la place de la "vraie" url, ces services se trouvent sur le chemin de la requête de l'internaute, et introduisent donc une possibilité de cassure de la requête :

• si le service de redirection est temporairement en panne ou, pire, s'il cesse son activité, l'url courte ne fonctionne plus et l'internaute ne peut accéder au document recherché
• le service de redirection doit être un prestataire de confiance : au lieu de rediriger correctement les requêtes qui lui sont faites, il lui est tout à fait possible de les rediriger vers des sites partenaires.
• TinyURL, pour ne citer que le plus gros des services de ce type, annonce à ce jour 222 millions d'urls "raccourcies", et 2 milliards de requêtes chaque mois. La centralisation de ce dépôt d'urls, qui couvrent pourtant des sources d'informations hétérogènes, va à l'encontre de la nature décentralisée du réseau internet. Au lieu d'un plan d'adressage des documents dont la responsabilité serait confié aux administrateurs des différents domaines, l'ensemble de l'adressage se trouve regroupé sur un nombre très limité de services de réduction d'urls.
• Certains services proposent à l'internaute de choisir lui-même le mot clé qui sera employé pour effectuer la redirection. Ce qui peut naturellement mener à certains abus. Quelques exemples, en vrac :
  • http://tinyurl.com/sarkozy renvoie vers http://www.korben.info/des-nouveautes-sur-korbeninfo.html
  • http://tinyurl.com/twiter renvoie vers http://www.pownce.com/

Lorsqu'il clique sur l'url courte, l'internaute n'a a priori aucun moyen de connaître quelle est l'url de destination de la redirection. Nommé "obfuscation d'url", cet inconvénient empêche une navigation sûre, et retire tout moyen de déterminer à l'avance, par son url, la nature du site qui va être affiché.

Le besoin d'outils open-source

Parmi les inconvénients cités ci-dessus, plusieurs pourraient être résolus par la multiplication du nombre de services de redirection d'urls.

En effet, un plus grand nombre de services de ce type éviterait qu'un seul de ces fournisseurs accapare l'intégralité des urls courtes, et réduirait donc l'influence potentielle de ce fournisseur (risque de black-out le jour où ce fournisseur fermera ses portes, tentation de rediriger frauduleusement du trafic vers des sites affiliés, etc.)

L'existence d'une ou de plusieurs solutions open-source serait donc bienvenue ; au même titre que les forums du type phpBB, Vanilla ou autre ont permis de ne pas centraliser les débats sur quelques plateformes professionnelles, de même que Dotclear, Wordpress and co. ont permis d'éviter que tous les blogs d'internet aient été hébergés chez 3 ou 4 gros fournisseurs, l'existence de quelques solutions open-source permettrait une multiplication rapide des services disponibles. Mieux : chaque site pourrait héberger son propre "réducteur d'url", et le diffuser le plus simplement possible à l'aide de l'attribut HTML rel=shortlink (lire rev=canonical, chez Anne Van Kesteren).

Et voici le schéma de fonctionnement idéal :

sfShortUrl, une implémentation open-source des URLs courtes

J'ai publié ce soir un plugin pour Symfony permettant de mettre aisément en place un système de redirections d'url. Alors allez-y : téléchargez, installez, enregistrez un domaine court, et à vous les urls courtes !

sfShortUrlPlugin est déjà employé par xav.cc, et n'attend plus que de nombreux autres déploiements.

written on

May 10th, 2009

tags:

php plugin short url symfony