Cette entrée n'utilise que des liens relatifs (sauf les liens
externes). Par exemple, le
lien vers l'entré précédente est
"../09/weblog.html". Si vous lisez cette
page à partir de son URI canonique (à savoir
http://www.raubacapeu.net/people/yves/2002/09/18/weblog.html
),
le lien relatif est facile à suivre. En revanche, tant que cette
page sera la dernière entrée, donc lue depuis l'URI
http://www.raubacapeu.net/people/yves/weblog.html
,
il semble logique que le lien relatif pointe sur
http://www.raubacapeu.net/people/09/weblog.html
.
Évidemment, c'est faux, même si quasiment TOUS les
navigateurs Web font cette erreur.
L'explication vient de la
RCF2616, plus
spécifiquement de la section 14.14 sur l'en-tête
"Content-Location
". En effet,
Jigsaw (le serveur de ce site),
est configuré pour que l'URI
http://www.raubacapeu.net/people/yves/weblog.html
aie la sémantique "dernière entrée", mais dans les
en-tête, on peut voir ceci:
Content-Location: http://www.raubacapeu.net/people/yves/2002/09/18.html
Ceci veut dire que l'entrée servie comme dernière
entrée est en fait à cet endroit. La spécification
HTTP/1.1 (plus connue sous le doux nom de
RCF2616) dit:
The value of Content-Location also defines the base URI
for the entity., ce qui veut dire que la base à partir de
laquelle on calcule les liens relatif à la page n'est pas l'URI
de la requète, mais celle donnée dans l'en-tête
Content-Location
s'il est présent, bien sûr.
donc "../09/weblog.html" devrait vous
amener à l'URL suivante:
http://www.raubacapeu.net/people/yves/2002/09/09/weblog.html
Un test est maintenant disponible dans la petite série de tests HTTP sur jigsaw.w3.org.
Si seulement les éditeurs de logiciels suivaient les normes, et si seulement les utilisateurs connaissaient les normes pour en tirer tous les usages et les sémantiques possibles...