Metalink, aria2 et uGet : le téléchargement, autrement

Metalink, aria2 et uGet : le téléchargement, autrement

Yakafokon

Avatar de l'auteur
David Legrand

Publié dans

Sciences et espace

27/11/2018 11 minutes
45

Metalink, aria2 et uGet : le téléchargement, autrement

Pour télécharger un fichier en toute sécurité, il faudrait penser à vérifier son intégrité et sa provenance. Des procédures souvent mises de côté, alors que des outils clé en main existent. Ils ont en plus l'avantage d'être open source et très efficaces. 

Lorsque vous voulez télécharger un fichier accessible sur internet, vous passez en général par votre navigateur. Ces derniers gèrent pour cela quelques protocoles de base, FTP disparaissant peu à peu

Les gestionnaires de téléchargement sont une manière d'améliorer les choses. Ils ont pour principal avantage de centraliser leur gestion (parfois au niveau d'un NAS), de proposer des fonctionnalités complémentaires et parfois « d'accélérer » la procédure en découpant le fichier à télécharger en de multiples morceaux/connexions.

Pour certains protocoles comme BitTorrent, qui ne sont que rarement supportés, il faut souvent se tourner vers des clients tiers. La face visible d'un malaise plus profond dans l'évolution de nos téléchargements.

Efficacité, sécurité : peut mieux faire

 

En effet, le téléchargement en ligne a toujours été « bête » et finalement peu sécurisé. Il s'organise le plus souvent depuis une source unique, sans vérification de l'intégrité du fichier une fois la procédure terminée. Ne parlons même pas d'une vérification de signature numérique, qui permettrait de s'assurer de sa provenance. 

C'est notamment pour cela que la pratique des boutiques applicatives (ou Stores) s'est développée ces dernières années, avec la promesse d'une recherche centralisée, de mises à jours automatiques et autres sources identifiées. Cela n'empêche bien entendu pas la propagation de malwares, mais c'est un bon début.

Les systèmes d'exploitation libres ont pourtant fait depuis longtemps des choix intéressants dans ce domaine, en proposant une diversité dans les sources d'approvisionnement. Le cas d'APT dans le monde Debian est un bon exemple avec une liste de dépôts que l'utilisateur peut compléter avec une gestion de clés publiques permettant de vérifier les signatures. 

APT

Ainsi, on peut télécharger et installer simplement de nombreuses applications, depuis différents serveurs (miroirs), mais aussi les mettre à jour. Le tout avec une vérification de leur intégrité et provenance à travers une signature cryptographique, ce qui permet d'éviter les principaux problèmes de sécurité.

Certains tentent d'aller plus loin, en reproduisant la mécanique des Stores de manière plus ouverte. C'est notamment le cas de Canonical qui travaille sur les Snaps, des packages pour Ubuntu et 40 autres distributions, ou de Flatpak. De son côté, AppImage se concentre sur la création de packages « qui tournent partout », sans mode de distribution particulier.

Mais voilà : lorsque vous téléchargez l'exécutable d'une application, l'image ISO de votre système d'exploitation préféré, une vidéo ou même un simple document, rien de tout cela n'est utilisé, pas même une petite protection.

Metalink, une solution (malheureusement) délaissée

Pourtant, calculer l'empreinte (hash) d'un fichier ou le signer n'est guère complexe. Pas plus que de mettre ces informations à disposition puisque tout est fait pour qu'elles puissent être échangées en format texte. On pourrait alors se dire que c'est parce que rien n'a jamais été standardisé : encore raté.

Le format Metalink existe depuis plus de dix ans et a fait l'objet de deux Request for Comments auprès de l'IETF : la RFC 5854 pour sa description générale et la RFC 6249 pour l'intégration aux headers HTTP. Un site est consacré au projet, on peut y trouver la description de la version 3.0 (la dernière étant la 4.0) et une liste d'implémentations

Mais depuis 2010/2015, le projet n'est plus très actif, malgré ses multiples intérêts. Même constat pour des outils annexes tels que MirrorBrain, qui devait en faciliter l'usage côté serveur. Pourtant, on peut encore en tirer parti. 

Metalink Exemple Slackware
Un fichier Metalink permettant de télécharger l'ISO de Slackware Linux

Mais qu'est-ce que Metalink ? Un fichier comprenant des métadonnées et basé sur le format XML (ou d'une réponse HTTP). Son objectif : connaître, pour un fichier, des informations de base (nom, taille, version, description) et une liste de miroirs, de sommes de contrôle (hash) et/ou sa signature.

Plusieurs types de liens peuvent être fournis via des protocoles comme FTP, HTTP et BitTorrent. Deux précisions principales peuvent être apportées : le pays où se situe le serveur et son ordre de priorité.

Dans l'idéal, ces informations évoluent selon l'emplacement de l'utilisateur. L'idée de départ de Metalink était en effet de favoriser l'émergence d'une solution de type CDN (Content Delivery Network) tout en exploitant la galaxie de miroirs que l'on trouve dans le domaine de l'open source. OpenSUSE était l'un de ses promoteurs (voir ci-dessous). 

Ainsi, lorsqu'il veut par exemple télécharger l'ISO d'une distribution, un utilisateur n'a en théorie qu'à récupérer le fichier Metalink, son gestionnaire de téléchargement peut ensuite décider quels miroirs utiliser, s'il ne faut pas plutôt basculer sur un lien BitTorrent, et vérifier à la fois l'intégrité et l'origine du fichier une fois l'opération terminée.

Une solution tout de même préférable au fait de placer hash et autres signatures dans des fichiers tiers, à récupérer manuellement et à vérifier individuellement via différents outils, comme trop souvent aujourd'hui.

  • Metalink ApachCon 2008
  • Metalink ApachCon 2008
  • Metalink ApachCon 2008
  • Metalink ApachCon 2008
  • Metalink ApachCon 2008
  • Metalink ApachCon 2008
  • Metalink ApachCon 2008

Qui utilise Metalink (ou ses alternatives) ?

On aurait pu imaginer que des acteurs du monde du logiciel libre, tels que Mozilla, allaient s'emparer d'une telle possibilité, mais cela n'a malheureusement jamais été le cas. Certains ont bien proposé une intégration à Firefox il y a 13 ans déjà, sans succès malgré quelques relances. La plus récente a trois ans.

Certaines distributions exploitent quand même Metalink et le proposent pour le téléchargement de leurs ISO, notamment Ubuntu (voir cet exemple). Mais le fichier fourni se repose toujours sur la version 3.0 du standard et des sommes de contrôle MD5 (qui ne sont plus considérées comme sûres depuis des années). 

Slackware propose de son côté des fichiers Metalink en versions 3.0 et 4.0 (voir cet exemple). Ils sont cette fois bien plus complets avec une signature GnuPG, des empreintes MD5, SHA-1 et SHA-256 et même l'utilisation de l'élément pieces (SHA-1) qui permet de déclarer un hash pour un ensemble de portions contiguës du fichier.

Debian et Ubuntu ont fait le choix de Jigdo (Jigsaw Download) ou Zsync qui permettent de compléter un téléchargement depuis une ancienne version où certains fichiers n'auraient pas été modifiés (comme les versions quotidiennes). Mais ils ne prennent pas directement en compte la signature cryptographique du fichier par exemple. 

Jigdo a également la spécificité de télécharger les paquets depuis différents miroirs puis d'effectuer une reconstruction locale de l'image ISO à la fin de la procédure, ce qui limite le besoin de stocker de gros fichiers dans les miroirs.

Peu d'applications gèrent Metalink

Se pose ensuite la question du client de téléchargement. Comme nous avons pu le voir, Metalink n'est pas géré par les navigateurs. Il existe bien une extension Chrome, mais elle n'a pas été mise à jour depuis 2013 et ne semble pas fonctionner correctement. Il faut donc se tourner vers des applications tierces. 

Et malheureusement, rares sont les gestionnaires de téléchargement à être encore maintenus activement, d'autant plus lorsqu'il s'agit de solutions open source. DownThemAll! est un exemple du genre, l'extension n'ayant toujours pas été portée au format WebExtension, afin de fonctionner avec  les nouvelles versions de Firefox.  

cURL, un outil très utilisé par les développeurs, permet de télécharger les fichiers Metalink : 

curl --metalink http://lelien.extension

Il ne fonctionnera pas toujours. Par exemple, le portage effectué par Microsoft pour Windows 10 ne gère pas cette possibilité, un message d'erreur étant simplement affiché.

Même des outils récents comme EagleGet, Free Download Manager ou le gestionnaire de téléchargement intégré à des NAS QNAP ou Synology ne reconnaissent pas les fichiers et ne peuvent donc exploiter leur contenu. Il existe néanmoins une solution simple à utiliser, multiplateformes et utile au-delà de Metalink : aria2.

aria2 : le client pour les télécharger tous

Derrière ce nom se cache un outil discret, mais utilisé par un nombre croissant d'applications pour gérer leurs procédures de téléchargement. Il faut dire qu'il est diablement efficace, paramétrable et surtout très complet.

Léger (moins de 4 Mo) il gère aussi bien les liens HTTP(S) que (S)FTP, BitTorrent ou Metalink. Il peut découper un téléchargement, ce qui s'avère utile si vous utilisez de multiples connexions, le mettre en pause, utiliser plusieurs sources pour un même fichier, plusieurs connexions pour une même source, récupérer des fichiers depuis une liste, etc.

aria2

Il s'utilise en ligne de commande ou via des interfaces JSON-RPC/XML-RPC (Remote Procedure Call). Il est disponible sous Linux, OS X, Windows et même Android. Vous pouvez également en tirer parti via des outils tiers tels qu'apt-fast sous Ubuntu. Pour ceux qui préfèrent les interfaces graphiques, WebUI-aria2 peut être une solution. 

Attention tout de même : si les signatures sont bien récupérées, elles ne sont pas vérifiées par le client, qui laisse ce soin à l'utilisateur ou à des applications tierces. Les empreintes peuvent l'être (-V ou --check-integrity).

uGet pour vous simplifier la vie

uGet est une alternative open source et multiplateforme. Disponible dans les dépôts de nombreuses distributions Linux, ce gestionnaire de téléchargement est également proposé sous Android, BSD et Windows. Il se récupère parfois de manière indépendante d'aria2, tout comme son pack de langues (au format 7z). On a vu plus pratique.

Sous Windows, une fois les fichiers décompressés, l'exécutable se trouve dans le répertoire bin de l'application. Le pack de langues est à placer dans le répertoire share. Les paramètres sont complets, permettant d'adapter l'interface (GTK3), surveiller la présence de certaines extensions de fichiers dans le presse-papiers pour un téléchargement automatique, limiter la bande passante, n'activer le téléchargement que de telle à telle heure, tels ou tels jours, etc. 

uGet

Pour chaque téléchargement vous pourrez définir une catégorie, une priorité, des miroirs, un nombre maximal de connexions, quelques paramètres techniques comme la récupération de l'horodatage, un proxy, des identifiants ou même un cookie de session. Aria2 sera à sélectionner en remplacement de cURL dans les paramètres de plugins. 

Metalink et aria2 : actes manqués ?

Au final, on ne peut donc que regretter que des outils tels qu'aria2 ne soient pas plus utilisées dans des applications ou même des OS récents. Les navigateurs ne proposent que le strict minimum en matière de téléchargement et des projets comme Firefox pourraient avoir tout intérêt à mieux s'interfacer avec de telles solutions. 

Certes, uGet « fait le job » sur de nombreuses plateformes, mais une gestion intégrée est toujours préférable. On pense là aussi à BSD/Linux et aux différentes distributions qui n'ont pas vraiment su tirer parti d'un tel format. À l'heure où la question de la centralisation des téléchargements se pose, ainsi que la sécurité de leur distribution ou même la simplicité d'usage en évitant des modèles fermés (stores), Metalink pourrait être une solution viable.

Encore faut-il qu'au-delà des plaintes entendues régulièrement, les standards existants soient utilisés. Le format est facile à prendre en main, les implémentations déjà là pour la distribution et le téléchargement. « Il n'y a plus qu'à » comme on dit. Cette évolution apparaît de plus en plus nécessaire. Un choix face auquel se retrouveront tous ceux qui proposent des fichiers en téléchargement dans les années à venir. En cas de problème, ils ne pourront pas dire que rien n'avait été fait.

Écrit par David Legrand

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Efficacité, sécurité : peut mieux faire

Metalink, une solution (malheureusement) délaissée

Qui utilise Metalink (ou ses alternatives) ?

Peu d'applications gèrent Metalink

aria2 : le client pour les télécharger tous

uGet pour vous simplifier la vie

Metalink et aria2 : actes manqués ?

Commentaires (45)


Belle initiative, malheureusement sans intégration de base dans les navigateurs, cela ne prendra pas (même si le proposer ne fait pas de mal).



Comme le GPG, j’ai beau le proposer partout, j’ai un client (et pourtant pas celui qui a les données les plus sensibles) qui l’utilise pour échanger avec moi…


C’est là que la position de Firefox est vraiment difficile à comprendre.


Très intéressant, je ne connaissais pas ces solutions.



J’en étais à vérifier (et il m’arrive de sauter l’étape <img data-src=" />) les hash à la main, car eux sont toujours fournis par les éditeurs sérieux.


Oui, le souci c’est que les hashs sont distribués de manière différente selon les éditeurs : jamais dans le même fichier, de la même manière, etc. Je m’étais même fait un outil pour me simplifier la création/vérification :&nbsp;



https://github.com/davlgd/CheckHash/releases



Là l’intérêt c’est justement d’avoir une même ressource qui regroupe tout : descriptif, miroirs, priorités, hashs, signatures, etc.








David_L a écrit :



C’est là que la position de Firefox est vraiment difficile à comprendre.





C’est certain qu’on pense d’abord à lui, mais est-ce que la maintenance d’une telle fonctionnalité n’est pas trop lourde pour la faire tout seul surtout si le projet ne bouge plus comme tu l’indiques ?



Bah il ne bouge plus trop (le format non plus du coup <img data-src=" />) mais existe et la question se posait également quand le projet était actif. En l’état il reste exploitable et exploité.&nbsp;



C’est juste que comme on en est à imaginer des usines à gaz pour sécuriser la distribution des outils, exploiter une solutions ouverte à tous et simple ça me semble être une bonne idée pour un navigateur libre qui se veut différent et innovant <img data-src=" />&nbsp;


d’un coté, on nous assommes de messages “télécharger, c’est voler!”

d’un autre, les utilisateurs lambda se contentent de chrome pour tout faire (quelques uns osent utiliser un autre navigateur)

Donc le pourcentage de personnes pouvant être intéressé par metalink se réduit très fortement. Si microsoft/apple/google n’y prêtent aucune attention, ce sera pas madame michou qui va y regarder. J’ai jamais entendu parler de ce projet, et j’ai jamais trouvé d’utilité au hash, sûrement à mes tords.



Donc pour moi, si aucun poids lourd (microsoft/apple/google) utilise metalink, il est condamné à disparaitre. Plus simple pour eux de s’acharner sur leurs usine à gaz personnelle, plutôt qu’un outil open source que n’importe qui pourrait trafiquer et dont ils perdraient le contrôle


Le début de l’article m’a fait penser à IPFS, mais bon, c’est un système de fichier…








David_L a écrit :



Bah il ne bouge plus trop (le format non plus du coup <img data-src=" />) mais existe et la question se posait également quand le projet était actif. En l’état il reste exploitable et exploité.&nbsp;



C’est juste que comme on en est à imaginer des usines à gaz pour sécuriser la distribution des outils, exploiter une solutions ouverte à tous et simple ça me semble être une bonne idée pour un navigateur libre qui se veut différent et innovant <img data-src=" />&nbsp;





Je suis bien d’accord, surtout que maintenant que tu as signalé cette solution, je vais me sentir obligé de l’utiliser et donc de faire un blabla à destination du visiteur pour qu’il capte (et ne l’utilise pas ^^ )



De toutes façons c’est un travail d’ensemble : navigateur, services qui proposent des fichiers, utilisateurs qui demandent à ce que ce soit proposé. Comme dit, toutes les briques sont là.


TDF l’utilise pour Libreoffice mais c’est peu mis en avant:

&nbsp;https://download.documentfoundation.org/libreoffice/stable/6.0.7/win/x86/LibreOf…





Reliable downloads

Metalink



http://download.documentfoundation.org/libreoffice/stable/6.0.7/win/x86/LibreOff… (IETF Metalink)

http://download.documentfoundation.org/libreoffice/stable/6.0.7/win/x86/LibreOff… (old (v3) Metalink)



P2P links



http://download.documentfoundation.org/libreoffice/stable/6.0.7/win/x86/LibreOff… (BitTorrent)

http://download.documentfoundation.org/libreoffice/stable/6.0.7/win/x86/LibreOff… (Magnet)



Zsync links



http://download.documentfoundation.org/libreoffice/stable/6.0.7/win/x86/LibreOff…&nbsp;





Mais on revient toujours au problème du non support par les navigateurs qui est essentiel.



En plus cela serait un bon moyen de déclarer les formats de fichier (qui n’a jamais télécharger un fichier s’est transformer en.txt).








Soriatane a écrit :



En plus cela serait un bon moyen de déclarer les formats de fichier (qui n’a jamais télécharger un fichier s’est transformer en.txt).





Un fichier qui se transforme ? Comment-est-ce possible ? Et c’est quoi un .txt ?



Je peux comprendre la position de Firefox.



Depuis des années, en commençant par sortir le client mail pour en faire Thunderbird + Firefox, ils ont cherché à réduire leur base de code qui est encore énorme donc difficile à gérer. Certaines fonctions récentes (les conteneurs, p.ex.) ont été également transformées en modules externes.



Ils pourraient peut-être faire de même pour Metalink, un module externe “officiel” recommandé.



Car en effet le format et la fonction ont l’air très intéressants, et le téléchargement Firefox gagnerait à s’améliorer un peu, sur un lien lent ou intermittent il pourrait se débrouiller un peu mieux pour les reprises.


Bah pendant longtemps ils se sont reposés sur le fait de DownThemAll! faisait le job (ce qui n’est plus le cas), après je doute que la base de code nécessaire pour gérer ça soit une inflation folle par rapport au reste <img data-src=" />


Mais, metalink n’est pas compatible avec le classique lien HTTP ?





Je m’étais en effet déjà fait la réflexion (je crois que ça remonte à 8-10ans), pour un site web, comme celui d’Ubuntu, un fichier peut représenté d’un seul coup une forte bande passante (genre l’ISO à la sortie de la dernière version d’Ubuntu). Or pour le protocole bittorent le nombre est au contraire un avantage.

D’où pourquoi je m’étais poser la question : pourquoi, il n’y a pas un standard (coté serveur et client) qui permet au serveur de propose de manière transparente au navigateur compatible un lien torrent/magnet au lieu du lien HTTP ? L’utilisateur clique sur le lien, si le site gère et que son navigateur est compatible/activé/autorisé, bam, ça passe sur un mixte HTTP/bittorent (ou full bittorent), sinon ça reste sur l’HTTP classique.


Comme dit, tu peux l’intégrer dans les headers ou via un fichier .meta/.meta4. M’enfin si le client ne gère pas les infos renvoyées… <img data-src=" />&nbsp;


Ah OK, en fait le fichier ne se transforme pas. J’ai failli avoir peur.



Reste à répondre à ma troisième question, pas par un lien cette fois, j’espère.


Un .txt c’est fichier texte ouvert par un éditeur de texte basique comme Notepad ++ ou Bloc-note sous Windows (gedit sous GNU/Linux).


Et pourquoi appelles-tu cela comme cela ?



J’ai des tas de fichiers textes dont le nom ne finit pas par .txt.



Ah oui, j’utilise plutôt vi pour éditer un fichier texte mais je suis un vieux con qui a utilisé des systèmes unix avant windows.








tazvld a écrit :



Je m’étais en effet déjà fait la réflexion (je crois que ça remonte à 8-10ans), pour un site web, comme celui d’Ubuntu, un fichier peut représenté d’un seul coup une forte bande passante (genre l’ISO à la sortie de la dernière version d’Ubuntu). Or pour le protocole bittorent le nombre est au contraire un avantage.

D’où pourquoi je m’étais poser la question : pourquoi, il n’y a pas un standard (coté serveur et client) qui permet au serveur de propose de manière transparente au navigateur compatible un lien torrent/magnet au lieu du lien HTTP ? L’utilisateur clique sur le lien, si le site gère et que son navigateur est compatible/activé/autorisé, bam, ça passe sur un mixte HTTP/bittorent (ou full bittorent), sinon ça reste sur l’HTTP classique.







Le navigateur “brave” fait ça









David_L a écrit :



C’est là que la position de Firefox est vraiment difficile à comprendre.





En même temps, les développeurs de Firefox ne savent plus quoi faire pour améliorer leur produit, et font donc un peu n’importe quoi (ou les chefs de projets, peu importe).



Un exemple, pour accélérer le démarrage de Firefox et gratter de la place, ils ont voulu intégrer le format de compression LZ4 pour au moins le profil. Au final seuls quelques fichiers ont été visés, et il aurait mieux fallu ne rien faire du tout, car…



…ils ont utilisé une version du format limite Alpha qui n’avait pas encore un header définitif. Les LZ4 Firefox ont donc un header spécial au navigateur -inexploitable par un logiciel avec la librairie officielle LZ4 sans un peu de travail- et mettre une version STABLE du format, personne n’a encore envie de le faire/travailler dessus :

https://bugzilla.mozilla.org/show_bug.cgi?id=1209390



L’idée était peut-être bonne, mais… quel développeur un MINIMUM SERIEUX peut penser que ce puisse être une bonne idée d’utiliser un format en version ALPHA ?&nbsp; Car une fois codé, la maintenance doit être faible… mais là il faut non seulement corriger mais aussi reconvertir les fichiers existants, donc beaucoup de travail pour une erreur qui n’aurait jamais dû exister car le bon sens aurait interdit de faire ça au départ.



J’ai dû mettre environ deux heures à l’époque à trouver une solution pour lire une sauvegarde de bookmarks en LZ4, car il n’y avait pas encore l’addon mozlz4-edit.



Je ne sais pas ce qui se passe chez Mozilla, mais ils naviguent à vue.



Brave intègre un client webtorrent, mais rien de plus.&nbsp;


dans le même genre (gratuit pour usage privé mais malheureusement pas open-source), j’utilise hashtab qui rajoute un onglet “hashages” dans les propriétés d’un fichier…








David_L a écrit :



Brave intègre un client webtorrent, mais rien de plus.







Ce n’est pas la demande de tazvld ? ou je n’ai pas compris ?









Soriatane a écrit :



Un .txt c’est fichier texte ouvert par un éditeur de texte basique comme Notepad ++ ou Bloc-note sous Windows (gedit sous GNU/Linux).









fred42 a écrit :



Et pourquoi appelles-tu cela comme cela ?



J’ai des tas de fichiers textes dont le nom ne finit pas par .txt.



Ah oui, j’utilise plutôt vi pour éditer un fichier texte mais je suis un vieux con qui a utilisé des systèmes unix avant windows.





Je crois que l’extension n’est pas un soucis, on peut balancer au navigateur le fichier avec les données qu’il faut. Txt ou pas, Firefox peut s’en sortir pour voir le texte dedans.



En plus, le fichier est codé en UTF-8 d’après ce que je vois.



Plutôt une mécanique ou depuis un simple lien on arrive sur du HTTP ou du BT fonction de ce qui est diponible (ce que propose grosso modo Metalink)


UTF8 avec ou sans BOM ? <img data-src=" />


Viens de voir ça. Sale histoire !



Je croyais que les standards, c’était… standards ^^


Tu es si jeune que ca pour encore croire au respect des normes et de la “solution idéale” (#NaziIT-PointGodwin) ? <img data-src=" />

https://xkcd.com/927/


Ça vous ait déjà arrivé que le fichier téléchargé soit différent ? Ça ne m’arrive seulement quand je merdouille le téléchargement (mais dans ce cas la taille est différente, ça se voit tout de suite). J’ai jamais eu de corruption pendant le transfert. De toute façon je vérifie tout le temps les isos au cas où (c’est arrivé qu’il y ait des repacks malveillants).


Ah ce Xkcd, un indispensable ^^



Je suis pas si jeune, mais dans le monde du dev’ oui, car je bosse pour une société informatique depuis que 3 ans.



J’ai encore quelques restes de ma naïveté envers les dev’, mais ça va mieux avec le temps…








boogieplayer a écrit :



Ce n’est pas la demande de tazvld ? ou je n’ai pas compris ?









David_L a écrit :



Plutôt une mécanique ou depuis un simple lien on arrive sur du HTTP ou du BT fonction de ce qui est diponible (ce que propose grosso modo Metalink)





Grosso merdo, comme dit @David_L, quelque chose de transparent pour un navigateur qui reste retrocompatible avec les navigateur qui ne gère pas le protocole (ou qui ne souhaite pas gérer : les films de vacances, en particulier ceux durant les canicules, on préfère les télécharger en toute discrétion.).

Dit autrement, d’un point de vu POO, on hérite du lien HTTP direct pour conserver la rétrocompatibilité mais on ajoute les méthodes pour aller taper dans les autres protocoles. Un navigateur gérant le protocole va tester si ces méthodes existent avant de télécharger selon le protocole disponible, les autres navigateur tapant directement dans le lien HTTP.



Mais, je n’ai pas l’impression que Metalink soit rétrocompatible avec les navigateur ne gérant pas le protocole. Je pense qu’avec du javascript, ça doit être possible mais je ne suis pas fan du javascript dans ce cas là, ça fait bidouille qui compense l’absence de standardisation. Alors qu’il faudrait juste que le serveur déclare au client qu’il gère ça.



Le navigateur peut très bien gérer la réponse HTTP, après le plus simple serait de gérer les liens meta4 et / ou faciliter leur découverte automatique.&nbsp;








tazvld a écrit :



Grosso merdo, comme dit @David_L, quelque chose de transparent pour un navigateur qui reste retrocompatible avec les navigateur qui ne gère pas le protocole (ou qui ne souhaite pas gérer : les films de vacances, en particulier ceux durant les canicules, on préfère les télécharger en toute discrétion.).

Dit autrement, d’un point de vu POO, on hérite du lien HTTP direct pour conserver la rétrocompatibilité mais on ajoute les méthodes pour aller taper dans les autres protocoles. Un navigateur gérant le protocole va tester si ces méthodes existent avant de télécharger selon le protocole disponible, les autres navigateur tapant directement dans le lien HTTP.



Mais, je n’ai pas l’impression que Metalink soit rétrocompatible avec les navigateur ne gérant pas le protocole. Je pense qu’avec du javascript, ça doit être possible mais je ne suis pas fan du javascript dans ce cas là, ça fait bidouille qui compense l’absence de standardisation. Alors qu’il faudrait juste que le serveur déclare au client qu’il gère ça.





Je comprends vraiment pas le rapport avec la POO.

À moins qu’à chaque évocation de rétrocompatibilité il faille en parler. Mais pourquoi?



Effectivement, j’avais mal compris. Sorry <img data-src=" />



Effectivement, ça n’existe pas, et il n’y a pas de protocole standardisé qui permettrait de s’en approcher facilement, sans bidouiller. Je rejoins David sur l-son questionnement par rapport à FF qui pourrait mettre en place le protocole qui authentifierai que l’object téléchargé est bien celui prévu par le fournisseur de l’objet et attendu par le demandeur de l’objet. Trop d’autres choses à faire avant sans doute.








Albirew a écrit :



dans le même genre (gratuit pour usage privé mais malheureusement pas open-source), j’utilise hashtab qui rajoute un onglet “hashages” dans les propriétés d’un fichier…





Il y a ca en alternative à HashTab et opensource&nbsp; :&nbsphttps://github.com/gurnec/HashCheck



Tu n’as pas été confronté à l’utilisateur windows lambda c’est tout. <img data-src=" />


Si, forcément, mais je ne me suis pas laissé influencer par leur mauvaises habitudes.


Le ‘fichier qui se transforme’ quand on modifie l’extension, c’est le changement de l’icône (associée à l’extension) que l’utilisateur constate. Rien de plus.



Donc un fichier .txt c’est celui avec l’icône idoine correspondant..



L’utilisateur lambda est de ce niveau de compréhension pour moi.


Je sais bien, qu’il y avait une idée de ce genre, mais j’attends plus d’un lecteur de NXI surtout quand il est capable ensuite de me mettre un lien sur les types MIME.


<img data-src=" /> Je n’avais pas senti la tentative pédagogique.


Mais euhh!!



J’ai fait une réponse vite fait entre deux.


nice! pas aussi brossé que l’autre mais le fait qu’il soit open-source compense largement =)

Merci =]


Effort de transmission, peut-être. Pour la pédagogie, on repassera <img data-src=" />