{"id":288,"date":"2012-09-04T19:36:39","date_gmt":"2012-09-04T17:36:39","guid":{"rendered":"http:\/\/blog.nebule.org\/?p=288"},"modified":"2016-03-29T19:04:59","modified_gmt":"2016-03-29T17:04:59","slug":"localisation-web","status":"publish","type":"post","link":"https:\/\/blog.nebule.org\/?p=288","title":{"rendered":"Localisation web"},"content":{"rendered":"

Chaque entit\u00e9 dispose par nature d’un identifiant unique, invariant et non cessible. C’est une cl\u00e9 cryptographique publique.<\/p>\n

Cependant cet identifiant ne pr\u00e9cise pas la place de l’entit\u00e9, ou plut\u00f4t la place o\u00f9 on peut la joindre.
\nLes entit\u00e9s, pour pouvoir \u00e9changer, doivent avoir une place publique, c’est la localisation.<\/p>\n

Cette place est-elle unique d’ailleurs?
\nEn fait non, l’entit\u00e9 peut \u00eatre pr\u00e9sente en de multiples places, soit par le biais de relais, soit parce que la cl\u00e9 priv\u00e9 aura \u00e9t\u00e9 vol\u00e9 et exploit\u00e9.<\/p>\n

Ce qui diff\u00e9rencie fortement l’entit\u00e9 d’une ressource web classique, c’est que l’entit\u00e9 est unique quelque soit sa localisation, et n’existe pas uniquement du fait de l’existence du serveur web qui l’h\u00e9berge. Cette entit\u00e9 survira \u00e0 la disparition d’un serveur web, sa r\u00e9silience est grandement am\u00e9lior\u00e9 et ne d\u00e9pend que faiblement de sont environnement.<\/p>\n

<\/p>\n

(Cette r\u00e9flexion est men\u00e9 en pr\u00e9ambule de l’exp\u00e9rience 4<\/span><\/a>)<\/span><\/p>\n

On va ici r\u00e9duire le probl\u00e8me \u00e0 des \u00e9changes via le protocole http<\/em>, et donc \u00e0 des places sur les serveurs web. Ces serveurs ayant un nom de domaine unique (et souvent une adresse IP unique).<\/p>\n

Cette localisation impose plusieurs choses :
\n1\/ d\u00e9finition<\/strong> de la localisation
\n2\/ attachement<\/strong> d’une localisation \u00e0 l’entit\u00e9
\n3\/ r\u00e9solution<\/strong> de la localisation<\/p>\n

1\/ D\u00e9finition<\/h2>\n

Se restreignant au web, la localisation est donc une URL de type http<\/em> ou https<\/em> (CF Wikipedia – URL [FR]<\/a> et RFC2616[EN]<\/a>.<\/p>\n

Une entit\u00e9 est-elle unique sur une URL donn\u00e9e? Ne faut-il pas pr\u00e9voir qu’une URL, et donc souvent un seul serveur, puisse h\u00e9berger plusieurs entit\u00e9s? Ces multiples entit\u00e9s pouvant n’\u00eatre que des automates au service d’une seule entit\u00e9.<\/p>\n

1.1\/ Champs<\/h3>\n

Les \u00e9l\u00e9ments qui doivent appara\u00eetre :
\n1- l’entit\u00e9
\n2- l’objet (source)<\/p>\n

Les \u00e9l\u00e9ments optionnels :
\n– la requ\u00eate sur un objet ou sur les liens
\n– l’objet cible
\n– l’objet m\u00e9ta
\n– la p\u00e9riode de temps<\/p>\n

Pour rappel, le lien a cette forme : Signature-HashSignataire-TimeStamp-Action-HashSource-HashCible-HashMeta<\/code><\/span>
\nOn retrouve des choses similaires avec ce que l’on veut obtenir : (?)-Entit\u00e9-P\u00e9riodeTemps-Requ\u00eate-Objet-ObjCible-ObjMeta<\/code><\/span><\/p>\n

1.2\/ Formes des URL<\/h3>\n

Il y a de multiples fa\u00e7ons d’int\u00e9grer des \u00e9l\u00e9ments dans une URL. On peut ainsi mettre quelques informations dans le nom de domaine, dans la partie r\u00e9pertoire ou fichier, ou sous forme d’options.<\/p>\n

On peut tout mettre en options de l’URL :
\n http:\/\/site.net?entit\u00e9=0123456789abcdef&objet=a9c66dbee3b73720<\/code>&req=liens<\/code><\/span>
\nCette forme d’URL est assez souple mais pas toujours facile \u00e0 lire. Mais apr\u00e8s tout, ce seront les machines qui la liront. Elle pr\u00e9sente n\u00e9anmoins l’avantage de nommer explicitement les champs ce qui est aussi une perte de place net pour les champs obligatoires qui, eux, peuvent \u00eatre pr\u00e9positionn\u00e9s de fa\u00e7on stricte.<\/p>\n

Une autre forme d’URL peut \u00eatre :
\n http:\/\/site.net\/0123456789abcdef\/a9c66dbee3b73720<\/code>\/l<\/code><\/span>
\nCette forme est plus courte, a des champs pr\u00e9positionn\u00e9s dont la signification est implicite, est reste assez lisible avec un peu de pratique. A part le d\u00e9but de l’URL, le nom de domaine et sa forme impos\u00e9s http:\/\/site.net\/<\/code>, pour la suite le s\u00e9parateur ‘\/’ peut \u00eatre remplac\u00e9 par un autre s\u00e9parateur.
\nMais comment cela se passe avec les champs optionnels?
\nDe plus, cette forme d’URL n\u00e9cessite soit une organisation strict est pr\u00e9-adapt\u00e9 des objets, soit un traitement\/traduction au niveau du serveur web.<\/p>\n

Une derni\u00e8re forme permet de placer un champs dans la partie nom de domaine, comme ceci :
\nhttp:\/\/0123456789abcdef<\/code>.site.net\/a9c66dbee3b73720\/l<\/code><\/span>
\nCette forme n’est pas plus courte que la pr\u00e9c\u00e9dente, cependant elle n\u00e9cessite aussi du travail de traitement\/traduction sur les URL c\u00f4t\u00e9 serveur web.<\/p>\n

1.3\/ Limites<\/h3>\n

Toutes ces formes sont possibles, tant que l’on respecte les contraintes des URL. Quelles limites avons nous sur les URL http?<\/p>\n

La limite de l’espace des caract\u00e8res utilisables. Nous utilisons les caract\u00e8res ASCII pour la date, le m\u00eame mais restreint \u00e0 l’alphabet pour les actions, et les chiffres en base hexad\u00e9cimale (0 \u00e0 9 et a \u00e0 f) pour les objets. Rien de tout cela n’est hors de ce que peut accepter une URL.<\/p>\n

La limite de taille de l’URL. Cette limite, telle que d\u00e9fini par la\u00c2\u00a0RFC2616[EN]<\/a> est uniquement d\u00e9pendante du bon vouloir des navigateurs et des serveurs web. Une \u00e9tude empirique<\/a> montre que c’est assez disparate (\u00e9tude de 2006 mais qui semble toujours d’actualit\u00e9) et qu’il est pr\u00e9f\u00e9rable de ne pas d\u00e9passer 2000 caract\u00e8res pour que tous les navigateurs puissent l’utiliser. Apache, par exemple (le serveur que j’utilise), est volontairement limit\u00e9 \u00e0 4000 caract\u00e8res, ce qui veut dire que l’on ne peut utiliser d’URL de plus grande taille en pratique.<\/p>\n

Une empreinte de 512bits (sha512sum par exemple) occupe 128 octets dans sa notation hexad\u00e9cimale affich\u00e9e en ASCII.
\nL’exemple ci-dessous fait 539 caract\u00e8res et utilise des empreintes de 512bits :
\n http:\/\/neb.nebule.org\/1693306c861103bce613b2537a1e6542c1d7cd00152c31feddd9c2853c6cafc868efae4fd20eb22485c63f404af9de11caa9fa8c13c24f8d848fd9279e80c5fc\/e1fe8e95010d855c097435e49055198e9ca70ee7dd301dc24533c3705773d354472344b45d5d286d35fd3a26f7c24b8d4c8491f119efaed2648994f41fb3dc06\/l\/779aca9c758c7d46fb537c013fae9cd1a529af276cf1e121a6870aad9987ad6a70232d92ecc665037fd24208b7b79be5960ad1de326365696665ed8c6f03aacd\/078ef386644bf75e8f3c2b3355d9347294344b889b0703da7bc14c02cb20e2d63cdf81158e4b3fd022352505996d90c2087d25241fb01c5dd03cc501a0223b74<\/code><\/span><\/p>\n

Cette exemple montre que, en utilisant sha512, l’URL sera inf\u00e9rieur \u00e0 600 caract\u00e8res.
\nDonc, au moins dans un premier temps et pour un avenir \u00e0 moyen terme, c’est utilisable.<\/p>\n

1.4\/ Variabilit\u00e9 de la forme<\/h3>\n

La requ\u00eate sur l’objet<\/em> ne peut prendre que deux valeurs, L ou O. C’est \u00e0 dire que l’on demande l’objet (son contenu) ou ses liens. Ce champ est optionnel, son absence signifie que l’on demande l’objet.
\nCette forte pr\u00e9d\u00e9termination permet une reconnaissance certaine de ce champ, quelque soit sa place dans l’URL.<\/p>\n

L’objet cible<\/em> et l’objet m\u00e9ta<\/em> sont des empreintes. L’empreinte est repr\u00e9sent\u00e9 par une suite de caract\u00e8res ASCII limit\u00e9s au n\u00e9cessaire pour repr\u00e9senter l’hexad\u00e9cimal, soit 16 caract\u00e8res possibles.
\nSauf quelques tr\u00e8s rares cas, ces objets ne sont pas \u00e9changeable dans les liens. Cela implique que si l’on demande l’un ou l’autre (avec l’objet source), on aura des r\u00e9ponses qui respectent le type de ce second (voir troisi\u00e8me) objet de l’URL.
\nIl n’est donc pas besoin de pr\u00e9ciser leur qualit\u00e9, et donc peuvent \u00eatre interchangeable \u00e0 condition que l’objet source<\/em> reste parfaitement identifiable.
\nLes rares cas d’interversion de ces deux objets peuvent facilement \u00eatre trait\u00e9s par l’entit\u00e9 qui fait la requ\u00eate.
\nDe plus, ces deux champs n’ont pas de raison d’\u00eatre si la requ\u00eate n’est pas L.<\/p>\n

La p\u00e9riode de temps<\/em> est plus probl\u00e9matique. Ce champ n’est pas encore pleinement d\u00e9finit m\u00eame si il sera restreint \u00e0 de l’ASCII.
\n\u00c9tant le seul champ aujourd’hui probl\u00e9matique, il peut simplement \u00eatre positionn\u00e9 \u00e0 la fin.
\nDe plus, ce champ n’a pas de raison d’\u00eatre si la requ\u00eate n’est pas L.<\/p>\n

L’entit\u00e9<\/em> doit-elle appara\u00eetre dans l’URL?
\nOn peut assumer le fait que, dans certains cas, une seule entit\u00e9 est accessible \u00e0 une adresse donn\u00e9e. Mais en supprimant l’information de l’entit\u00e9 que l’on vise, cela r\u00e9duit de fait les \u00e9changes \u00e0 ce que propose directement l’entit\u00e9 attach\u00e9e \u00e0 l’URL, et exclue donc la possibilit\u00e9 de r\u00e9cup\u00e9rer des informations qui ne sont pas li\u00e9es \u00e0 cette entit\u00e9.
\nMais si l’entit\u00e9 derri\u00e8re l’URL est unique, elle h\u00e9berge des objets qui sont accessibles de fa\u00e7on arborescente. Et si une entit\u00e9, en tant que relai, h\u00e9berge une copie d’une autre entit\u00e9, cette entit\u00e9 h\u00e9berg\u00e9e h\u00e9rite en localisation d’une sous-lien de cette entit\u00e9 relai. Cette entit\u00e9 h\u00e9berg\u00e9 peut naturellement ajouter ce sous-lien dans ses localisations, et devient ainsi accessible aussi \u00e0 cette adresse.
\nLe champ entit\u00e9<\/em> peut donc ne pas \u00eatre pr\u00e9sent dans l’URL, et ne doit pas \u00eatre interpr\u00e9t\u00e9 comme un champ mais utilis\u00e9 tel quel.
\nComment vont pouvoir se propager des liens sur des objets que l’on h\u00e9berge mais dont on est pas signataire, des liens que l’on partage \u00ab\u00a0par relation de confiance\u00a0\u00bb? Cet aspect n’est pas encore \u00e9tudi\u00e9 et sera r\u00e9solu plus tard.<\/p>\n

Il en r\u00e9sulte que la place des champs est fixe et en premi\u00e8res positions pour l’entit\u00e9<\/em> et l’objet source<\/em>, ainsi que en derni\u00e8re position pour la p\u00e9riode de temps<\/em> \u00e9ventuelle. Et les autres champs sont plac\u00e9s si besoin entre.
\nCependant, dans un premier temps et par simplification, on n’utilisera pas, l’entit\u00e9<\/em>, l’objet cible<\/em>, l’objet m\u00e9ta<\/em> et la p\u00e9riode de temps<\/em>. Ensuite, on rend obligatoire et non plus optionnel la requ\u00eate sur l’objet<\/em>. Cela r\u00e9duit donc les champs utilis\u00e9s \u00e0 l’objet source<\/em>\u00c2\u00a0 et la requ\u00eate sur l’objet<\/em>.<\/p>\n

Cette propri\u00e9t\u00e9 arborescente, qui n’a pas vocation \u00e0 \u00eatre directement propag\u00e9e, offre une souplesse qui pourra \u00eatre exploit\u00e9 plus tard. Mais impose une contrainte suppl\u00e9mentaire sur l’URL qui va permettre les \u00e9changes. On doit pouvoir distinguer ce qui appartient \u00e0 l’URL de base<\/em>, fourni comme localisation d’une entit\u00e9, et les champs optionnels. Ne pas utiliser ces champs optionnels dans un premier temps simplifie grandement le probl\u00e8me. Ces champs optionnels pourront ensuite \u00eatre int\u00e9gr\u00e9s sous forme d’options de l’URL.<\/p>\n

1.5\/ Forme<\/h3>\n

Il faut d\u00e9finir une mani\u00e8re commune de travailler, un protocole.<\/p>\n

Dans un premier temps, ce protocole doit \u00eatre assez stricte dans la d\u00e9finition de la forme des URL utilis\u00e9es. Il pourra ensuite \u00eatre assoupli avec les retours d’exp\u00e9riences.<\/p>\n

L’URL retenu est de la forme :
\n http:\/\/server.net\/Objet<\/span>\/Requ\u00eate<\/span><\/code><\/span>
\nAvec un traitement de l’URL c\u00f4t\u00e9 serveur, ou un pr\u00e9-agencement des fichiers.<\/p>\n

Soit, par exemple, le t\u00e9l\u00e9chargement d’un objet :
\n http:\/\/neb.starend.org\/bed8ee9b19b156d94ca6c5bdc359f6e4\/6e0f296c00bfebe8587d14b5eaf67786<\/span>\/o<\/span><\/code><\/span>
\net le t\u00e9l\u00e9chargement des liens de cet objet :
\n http:\/\/neb.starend.org\/bed8ee9b19b156d94ca6c5bdc359f6e4\/6e0f296c00bfebe8587d14b5eaf67786<\/span>\/l<\/span><\/code><\/span><\/p>\n

2\/ Attachement<\/h2>\n

L’entit\u00e9 doit \u00eatre capable par ses propres moyens de partager sa ou ses localisations. Chaque localisation est un objet contenant une URL, objet li\u00e9 \u00e0 l’entit\u00e9 par un objet m\u00e9ta le d\u00e9finissant comme \u00e9tant une localisation.<\/p>\n

L’objet contenant la localisation est donc un objet de type texte contenant uniquement l’URL.<\/p>\n

L’objet m\u00e9ta contient uniquement le texte \u00ab\u00a0nebule\/entite\/localisation<\/code>\u00ab\u00a0.<\/p>\n

3\/ R\u00e9solution<\/h2>\n

La derni\u00e8re \u00e9tape permet \u00e0 toute entit\u00e9 de retrouver une autre entit\u00e9 ainsi que ses localisations. C’est classiquement le r\u00f4le d’annuaire.<\/p>\n

L’annuaire peut \u00eatre impl\u00e9ment\u00e9 comme une entit\u00e9 relai qui tient \u00e0 jour et partage les entit\u00e9s abonn\u00e9es (objets cl\u00e9 publique) ainsi que les objets de localisations associ\u00e9s.<\/p>\n

Pour qu’une r\u00e9solution marche, il faut disposer au moins d’une localisation valide et accessible.<\/p>\n","protected":false},"excerpt":{"rendered":"

Chaque entit\u00e9 dispose par nature d’un identifiant unique, invariant et non cessible. C’est une cl\u00e9 cryptographique publique. Cependant cet identifiant ne pr\u00e9cise pas la place de l’entit\u00e9, ou plut\u00f4t la place o\u00f9 on peut la joindre. Les entit\u00e9s, pour pouvoir \u00e9changer, doivent avoir une place publique, c’est la localisation. Cette place est-elle unique d’ailleurs? En … Continuer la lecture de Localisation web<\/span><\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[93,101,24],"tags":[280,281],"_links":{"self":[{"href":"https:\/\/blog.nebule.org\/index.php?rest_route=\/wp\/v2\/posts\/288"}],"collection":[{"href":"https:\/\/blog.nebule.org\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.nebule.org\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.nebule.org\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.nebule.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=288"}],"version-history":[{"count":1,"href":"https:\/\/blog.nebule.org\/index.php?rest_route=\/wp\/v2\/posts\/288\/revisions"}],"predecessor-version":[{"id":2346,"href":"https:\/\/blog.nebule.org\/index.php?rest_route=\/wp\/v2\/posts\/288\/revisions\/2346"}],"wp:attachment":[{"href":"https:\/\/blog.nebule.org\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=288"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.nebule.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=288"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.nebule.org\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=288"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}