{"id":89253,"date":"2020-07-21T01:42:24","date_gmt":"2020-07-20T23:42:24","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/krutye-uri-ne-izmenyayutsya"},"modified":"2020-07-21T01:42:24","modified_gmt":"2020-07-20T23:42:24","slug":"krutye-uri-ne-izmenyayutsya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/krutye-uri-ne-izmenyayutsya","title":{"rendered":"Les URI magiques ne changent pas","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

L'auteur \u2014 Sir Tim Berners-Lee, inventeur des URI, URL, HTTP, HTML et du Web, actuellement directeur du W3C. L'article a \u00e9t\u00e9 r\u00e9dig\u00e9 en 1998. <\/p>\n

Quel URI peut-on consid\u00e9rer comme \u00ab cool \u00bb ?
\nCelle qui ne change pas.
\nComment les URI changent-elles ?
\nLes URI ne changent pas : ce sont les gens qui les modifient.<\/i> <\/p>\n

En th\u00e9orie, les gens n'ont aucune raison de modifier les URI (ou de cesser de maintenir les documents), mais en pratique, il y en a des millions.<\/p>\n

Th\u00e9oriquement, le propri\u00e9taire nominal d'un espace de noms de domaine poss\u00e8de effectivement cet espace et, par cons\u00e9quent, tous les URI qu'il contient. \u00c0 part en cas d'insolvabilit\u00e9, rien n'emp\u00eache le titulaire d'un nom de domaine de le conserver. Et th\u00e9oriquement, l'espace URI sous votre nom de domaine est enti\u00e8rement sous votre contr\u00f4le, vous pouvez donc le rendre aussi stable que vous le souhaitez. En grande partie, la seule raison valable pour laquelle un document peut dispara\u00eetre d'Internet est que l'entreprise propri\u00e9taire du nom de domaine a ferm\u00e9 boutique ou n'est plus en mesure de faire fonctionner son serveur. Alors pourquoi y a-t-il tant de liens morts dans le monde ? En partie, c'est simplement un manque de pr\u00e9voyance. Voici quelques raisons que l'on peut entendre :
\n<\/a><\/noindex><\/p>\n

Nous avons simplement r\u00e9organis\u00e9 le site pour l'am\u00e9liorer.<\/h4>\n

\nPensez-vous vraiment que les anciens URI ne peuvent plus fonctionner ? Si c'est le cas, vous les avez mal choisis. Pensez \u00e0 l'avenir pour que les nouveaux restent apr\u00e8s la prochaine refonte.<\/p>\n

Nous avons tellement de mat\u00e9riel que nous ne pouvons pas suivre ce qui est obsol\u00e8te, ce qui est confidentiel et ce qui est encore pertinent, donc nous avons pens\u00e9 qu'il serait mieux de tout d\u00e9connecter.<\/h4>\n

\nJe ne peux que vous plaindre. Le W3C a travers\u00e9 une p\u00e9riode o\u00f9 nous devions soigneusement examiner les archives pour des questions de confidentialit\u00e9 avant de les rendre publiques. La d\u00e9cision doit \u00eatre bien r\u00e9fl\u00e9chie \u00e0 l'avance : assurez-vous de documenter pour chaque document un cercle de lecteurs acceptable, une date de cr\u00e9ation et, id\u00e9alement, une dur\u00e9e de conservation. Conservez ces m\u00e9tadonn\u00e9es.<\/p>\n

Eh bien, nous avons d\u00e9couvert qu'il fallait d\u00e9placer des fichiers\u2026<\/h4>\n

\nC'est l'une des excuses les plus pitoyables. Beaucoup ignorent que les serveurs web vous permettent de g\u00e9rer la connexion entre l'URI d'un objet et son emplacement r\u00e9el dans le syst\u00e8me de fichiers. Imaginez l'espace URI comme un espace abstrait, parfaitement organis\u00e9. Ensuite, mappez-le \u00e0 n'importe quelle r\u00e9alit\u00e9 que vous utilisez r\u00e9ellement pour le mettre en \u0153uvre. Puis communiquez-le \u00e0 votre serveur web. Vous pouvez m\u00eame \u00e9crire un fragment de votre serveur pour faire tout cela correctement.<\/p>\n

John ne prend plus en charge ce fichier, c'est maintenant Jane qui le fait.<\/p>\n

Le nom de John \u00e9tait-il dans l'URI ? Non, il \u00e9tait juste dans son r\u00e9pertoire ? D'accord.<\/p>\n

Auparavant, nous utilisions un script CGI pour cela, et maintenant nous utilisons un programme binaire.<\/h4>\n

\nIl existe une id\u00e9e folle selon laquelle les pages cr\u00e9\u00e9es par des scripts devraient \u00eatre plac\u00e9es dans la zone \"cgibin\" ou \"cgi\". Cela r\u00e9v\u00e8le comment vous configurez votre serveur web. Changez le m\u00e9canisme (m\u00eame en conservant le contenu), et hop \u2014 tous vos URI changent.<\/p>\n

Prenons par exemple la National Science Foundation (NSF) :<\/p>\n

Documents en ligne de la NSF<\/p>\n

http:\/\/www.nsf.gov\/cgi-bin\/pubsys\/browser\/odbrowse.pl<\/pre>\n
\nLa premi\u00e8re page pour commencer \u00e0 consulter les documents ne restera manifestement pas la m\u00eame dans quelques ann\u00e9es. cgi-bin<\/code>, oldbrowse<\/code> et pl<\/code>\u00a0\u2014 tout cela donne des indices sur comment-nous-le-faisons-maintenant. Si vous utilisez une page pour trouver un document, vous obtiendrez \u00e9galement un r\u00e9sultat m\u00e9diocre :<\/p>\n
Rapport du groupe de travail sur la cryptologie et la th\u00e9orie du codage<\/p>\n
http:\/\/www.nsf.gov\/cgi-bin\/getpub?nsf9814<\/pre>\n
\npour la page d'index du document, bien que le document html lui-m\u00eame soit bien meilleur :<\/p>\n
http:\/\/www.nsf.gov\/pubs\/1998\/nsf9814\/nsf9814.htm<\/pre>\n
\nIci, le titre pubs\/1998 donnera \u00e0 tout futur service d'archivage une bonne cl\u00e9 pour comprendre le fonctionnement de l'ancienne classification des documents de 1998. Bien qu'en 2098, les num\u00e9ros de documents puissent sembler diff\u00e9rents, je peux imaginer que cet URI sera toujours valide, et cela n'entravera en rien la NSF ou toute autre organisation qui maintiendra l'archive.<\/p>\n
Je ne pensais pas que les URL devaient \u00eatre permanentes \u2014 il y avait des URN.<\/h4>\n
\nC'est probablement l'un des pires effets secondaires de la discussion sur les URN. Certains pensent qu'en raison des recherches sur un espace de noms plus permanent, ils peuvent se permettre d'\u00eatre n\u00e9gligents avec les liens cass\u00e9s, car \u00ab les URN r\u00e9soudront tout cela \u00bb. Si vous \u00eates l'une de ces personnes, laissez-moi vous d\u00e9cevoir.<\/p>\n
La plupart des sch\u00e9mas URN que j'ai vus ressemblent \u00e0 un identifiant d'autorit\u00e9, suivi soit d'une date et d'une cha\u00eene que vous choisissez, soit simplement d'une cha\u00eene que vous choisissez. Cela ressemble beaucoup \u00e0 une URI HTTP. En d'autres termes, si vous pensez que votre organisation sera capable de cr\u00e9er des URN durables, prouve-le d\u00e8s maintenant en les utilisant pour vos URI HTTP. Il n'y a rien dans HTTP qui rendrait votre URI instable. Seule votre organisation le peut. Cr\u00e9ez une base de donn\u00e9es qui associe l'URN du document au nom de fichier actuel, et laissez le serveur web l'utiliser pour extraire r\u00e9ellement les fichiers.<\/p>\n
Si vous \u00eates arriv\u00e9 \u00e0 ce stade, alors si vous n'avez pas le temps, l'argent et les contacts pour d\u00e9velopper un logiciel, vous pouvez faire la d\u00e9claration d'excuse suivante :<\/p>\n
Nous voulions, mais nous n'avons tout simplement pas les outils n\u00e9cessaires.<\/h4>\n
\nC'est vraiment dommage. Je suis tout \u00e0 fait d'accord. Ce que vous devez faire, c'est obliger le serveur web \u00e0 traiter instantan\u00e9ment l'URI permanent et \u00e0 renvoyer le fichier, peu importe o\u00f9 il est actuellement stock\u00e9 dans votre syst\u00e8me de fichiers fou. Vous voulez stocker tous les URI dans un fichier en tant que v\u00e9rification et maintenir constamment la base de donn\u00e9es \u00e0 jour. Vous souhaitez conserver les relations entre les diff\u00e9rentes versions et traductions d'un m\u00eame document, ainsi que maintenir un enregistrement ind\u00e9pendant de somme de contr\u00f4le pour garantir la protection contre la corruption de fichier due \u00e0 une erreur accidentelle. Et les serveurs web ne sont tout simplement pas livr\u00e9s avec ces fonctionnalit\u00e9s. Lorsque vous souhaitez cr\u00e9er un nouveau document, votre \u00e9diteur vous demande de sp\u00e9cifier l'URI.<\/p>\n
Vous avez besoin de la capacit\u00e9 \u00e0 modifier la propri\u00e9t\u00e9, l'acc\u00e8s au document, le niveau de s\u00e9curit\u00e9 au niveau d'archivage, etc., dans l'espace URI sans modifier l'URI.<\/p>\n
Tout cela est tr\u00e8s mal. Mais nous allons r\u00e9parer cela. Au W3C, nous utilisons la fonctionnalit\u00e9 Jigedit (serveur Jigsaw pour l'\u00e9dition), qui suit les versions, et nous exp\u00e9rimentons avec des scripts de cr\u00e9ation de documents. Si vous d\u00e9veloppez des outils, des serveurs et des clients, faites attention \u00e0 ce probl\u00e8me !<\/p>\n
Cette excuse s'applique \u00e9galement \u00e0 de nombreuses pages du W3C, y compris celle-ci : alors faites ce que je dis, et non ce que je fais.<\/p>\n
Pourquoi cela devrait-il m'inqui\u00e9ter ?<\/h1>\n
\nLorsque vous modifiez l'URI de votre serveur, il est impossible de savoir qui a des liens vers l'ancien URI. Cela peut \u00eatre des liens provenant de pages web ordinaires. Des favoris vers votre page. L'URI a pu \u00eatre griffonn\u00e9 sur les marges d'une lettre \u00e0 un ami.<\/p>\n
Lorsque quelqu'un clique sur un lien qui est cass\u00e9, il perd g\u00e9n\u00e9ralement confiance dans le propri\u00e9taire du serveur. Il est \u00e9galement d\u00e9\u00e7u - \u00e0 la fois \u00e9motionnellement et r\u00e9ellement - de ne pas pouvoir atteindre son objectif.<\/p>\n
Beaucoup de gens se plaignent r\u00e9guli\u00e8rement des liens cass\u00e9s, et j'esp\u00e8re que les dommages sont \u00e9vidents. J'esp\u00e8re que les d\u00e9g\u00e2ts r\u00e9putationnels pour le responsable du serveur o\u00f9 le document a disparu sont \u00e9galement clairs.<\/p>\n
Alors que dois-je faire ? Concevoir un URI.<\/h1>\n
\nIl est de la responsabilit\u00e9 du webmaster de concevoir des URI qui pourront \u00eatre utilis\u00e9s dans 2 ans, dans 20 ans, dans 200 ans. Cela n\u00e9cessite r\u00e9flexion, organisation et d\u00e9termination.<\/p>\n
Les URI changent lorsque des informations sont modifi\u00e9es. Il est tr\u00e8s important de savoir comment vous les concevez. (Quoi, concevoir un URI ? Je dois penser \u00e0 concevoir un URI ? Oui, vous devez y r\u00e9fl\u00e9chir). Concevoir signifie principalement ne pas inclure d'informations dans l'URI.<\/p>\n
La date de cr\u00e9ation du document - la date de d\u00e9livrance de l'URI - est une donn\u00e9e qui ne changera jamais. Elle est tr\u00e8s utile pour diff\u00e9rencier les requ\u00eates utilisant le nouveau syst\u00e8me de celles utilisant l'ancien syst\u00e8me. C'est un bon point de d\u00e9part pour l'URI. Si une date est mentionn\u00e9e sur le document, m\u00eame si le document sera pertinent \u00e0 l'avenir, c'est un bon d\u00e9but.<\/p>\n
La seule exception est la page qui est d\u00e9lib\u00e9r\u00e9ment consid\u00e9r\u00e9e comme la \u00ab derni\u00e8re \u00bb version, par exemple pour toute l'organisation ou une grande partie de celle-ci.<\/p>\n
http:\/\/www.pathfinder.com\/money\/moneydaily\/latest\/<\/pre>\n
\nC'est la derni\u00e8re colonne de Money Daily dans le magazine Money. La raison principale pour laquelle cette URI n'a pas besoin de date est qu'il n'y a aucune raison de conserver un URI qui survivra au magazine. La notion de Money Daily dispara\u00eetra lorsque Money dispara\u00eetra. Si vous souhaitez faire r\u00e9f\u00e9rence au contenu, vous devez le r\u00e9f\u00e9rencer s\u00e9par\u00e9ment dans les archives :<\/p>\n
http:\/\/www.pathfinder.com\/money\/moneydaily\/1998\/981212.moneyonline.html<\/pre>\n
\n(Cela a l'air bien. Cela suppose que \"money\" signifiera la m\u00eame chose tout au long de l'existence de pathfinder.com. Il y a une duplication de \"98\" et un inutile \".html\", mais \u00e0 part cela, il semble s'agir d'un URI solide.<\/p>\n
\u00c0 laisser de c\u00f4t\u00e9<\/h4>\n
\nTout ! \u00c0 part la date de cr\u00e9ation, en mettant quoi que ce soit dans l'URI, vous invitez d'une mani\u00e8re ou d'une autre aux probl\u00e8mes.<\/p>\n