Ce RFC met officiellement fin à une amusante tradition, qui était un des charmes des protocoles TCP/IP mais qui, en pratique, a causé quelques ennuis, justifiant son abandon. Cette tradition concernait le nommage des paramètres dans les protocoles. Normalement, ces noms étaient enregistrés à l'IANA pour éviter des collisions (par exemple, il ne doit y avoir qu'un seul champ nommé User-Agent: dans une requête HTTP). Comme cet enregistrement nécessitait une procédure, parfois lente et lourde, cela contrariait les gens qui voulaient expérimenter avec une nouvelle idée, qui impliquait un nouveau paramètre. L'habitude, avec l'appui de quelques RFC, s'était donc répandue de donner à ces paramètres expérimentaux, non officiels, un nom commençant par la lettre X suivie d'un tiret. Cette pratique a rencontré plusieurs problèmes et est donc désormais fortement déconseillée.
Ma synthèse en français : http://www.bortzmeyer.org/6648.html
Le RFC 6648 lui-même : http://www.rfc-editor.org/rfc/rfc6648.txt
# Pourquoi faire ?
Posté par Obsidian . Évalué à 10.
Merci beaucoup pour cette synthèse qui m'a l'air assez fidèle !
Mais alors, je ne comprend vraiment pas l'intérêt d'une telle mesure. Si je l'ai bien comprise, l'argument principal réside dans le fait qu'un en-tête expérimental peut éventuellement devenir officiel un jour et qu'à ce moment, ce sera chiant de convertir les programmes existants, et sous ce prétexte il faudrait leur enlever tous les signes distinctifs qui permet de les reconnaître comme tels et éventuellement de les filtrer facilement.
Je trouve ça idiot. D'abord, on sera toujours obligé de prendre en compte les anciens « X- » existants. Ensuite, chaque fois qu'on verra poindre un de ces trucs dans ses logs, il va falloir recompulser toutes les RFC pour voir si « X-Moron-Score » a été officialisé ou pas.
Pourquoi ne pas avoir, au contraire, officialisé la chose en publiant une RFC qui stipule que « X-Argument » = « Argument » ? Ça serait resté compatible et transparent avec l'existant et permis d'éviter toute modif' lors de la normalisation de l'en-tête-candidat. En plus, il serait resté très facile d'ajouter un switch pour choisir d'adopter cette attitude ou pas.
Les seuls cas qui auraient alors posé problème sont les homonymes du style « X-ArgumentExistantDéjàPris » qui sont en soi une pratique débile et tout aussi dépréciée par la même RFC.
[^] # Re: Pourquoi faire ?
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 5.
Cela ne me semble pas une bonne idée. Cela interdirait, lors de la normalisation d'un paramètre, de changer son nom (je prends X-billgates-est-un-con et ensute, je demande l'enregistrement officiel) ou de changer sa sémantique (ce qui est souvent le cas en pratique).
Sinon, pour savoir lesquels sont officiels, il ne faut surtout pas « compulser les RFC » (beaucoup de registres de paramètres n'exigent pas forcément un RFC, juste une doc stable) mais le registre pertinent sur le site de l'IANA http://www.iana.org/
[^] # Re: Pourquoi faire ?
Posté par Obsidian . Évalué à 3.
Ben non, pourquoi ? Rien ne t'interdit de changer d'en-tête si l'envie t'en prend. Ça implique effectivement un changement de tes spécifications et de ton programme, mais ce ne serait en rien différent de l'existant.
Note bien que, dans ma remarque, je ne proposais pas de rendre officiels les noms commençant par « X- » qui, eux, resteraient expérimentaux par nature, mais au contraire d'officialiser la tradition qui consiste à le faire, d'une part, ce qui revient à créer un namespace de test, et d'autre part poser la règle selon laquelle un header sans préfixe « X- », donc normalisé, serait équivalent au même header avec préfixe.
# eXtended
Posté par Anonyme . Évalué à 3.
Pour moi, X-, ça veut pas forcément dire que le paramètre est temporaire, bien au contraire. Pour moi c’est plutôt pour « eXtended » et cela signifie que c’est un paramètre qui n’a pas forcément à voir avec le protocole en lui même.
Par exemple, «
X-Spam-Status:», ajouté par SpamAssassin.[^] # Re: eXtended
Posté par Obsidian . Évalué à 5.
Personne n'a dit que c'était temporaire. La RFC les décrit comme « eX-perimentals ».
[^] # Re: eXtended
Posté par Anonyme . Évalué à 3.
Expérimental induit temporaire non ?
Enfin, pour moi expérimental, ça veut dire que ça va, soit disparaître, soit devenir officiel.
[^] # Re: eXtended
Posté par Obsidian . Évalué à 2.
Tout-à-fait. Dans le dernier cas, le header est pérénisé pour de bon. Mais s'il devient officiel, il perd son « X- ».
Et encore, le « temporaire qui dure » est un concept plutôt bien ancré.
# En nimage
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à -6.
Ça manquait d'une illustration, voici donc la nimage de rigueur :
# Similitudes
Posté par Guillaume Denry (site web personnel) . Évalué à 2.
Marrant, ça me rappelle un peu les différents avis autour des nouveaux champs dans les CSS, avec les vendor prefixes pour implémenter en avance de phase de nouvelles fonctionnalités avant leur standardisations.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.