Nouvelle RFC sur les champs structurés, tout comme mon package Javascript

Une nouvelle RFC a été publiée pour les champs structurés : RFC9651.

Qu'est-ce que c'est?

Les en-têtes HTTP ont été un peu gratuits en termes de complexité des valeurs
sont codés, avec de nombreux en-têtes nécessitant leur propre mini-analyseur.

Il y a quelque temps, un effort a été lancé pour résoudre ce problème pour les en-têtes à venir, nommés « Champs structurés ». Ils sont appelés champs et non « en-têtes » car HTTP a à la fois des en-têtes et des bandes-annonces !

Les champs structurés vous permettent d'encoder des éléments tels que des listes, des dictionnaires, des chaînes, des nombres, des booléens et des données binaires. La RFC originale de 2021 connaît un certain succès et bien que de nombreux en-têtes existants ne puissent pas être adaptés à ce format, de nombreuses nouvelles normes en profitent.

Quelques exemples :

// Parsed an ASCII string
Header: "foo"

// A simple string, called a 'Token' in the spec
Header: foo

// Parsed as number
Header: 5
Header: -10
Header: 5.01415

// Parsed into boolean
Header: ?1
Header: ?0

// Binaries are base64 encoded
Header: :RE0gbWUgZm9yIGEgZnJlZSBjb29raWU=:

// Items can have parameters
Header: "Hello world"; a="5"

// A simple list
Header: 5, "foo", bar, ?1

# Each element can have parameters
Header: sometoken; param1; param2=hi, 42

// A list can also contain lists itself. These are called 'inner lists' and
// use parenthesis
Header: sometoken, (innerlistitem1 innerlistitem2), (anotherlist)

// A simple dictionary
Header: fn="evert", ln="pot", coffee=?1

// Each item may have parameters too
Header: foo=123; q=1, bar=123, q=0.5

// A dictionary value may be an inner list again
Header: foo=(1 2 3)

La nouvelle RFC publiée la semaine dernière ajoute 2 nouveaux types de données : Dates et
« Chaînes d'affichage », qui est une sérialisation Unicode qui s'adapte au format d'en-tête (et de fin) HTTP.

// Parsed into a Date object<br>
Header: @1686634251

<p>// A Unicode string, called a 'Display String' in the spec. They use<br>
// percent encoding, but encode a different set of characters than<br>
// URLs.<br>
Header %"Frysl%C3%A2n"<br>
</p>

Pourquoi devriez-vous vous en soucier ?

Si vous rencontrez ces en-têtes dans la nature, c'est une très bonne idée d'utiliser un analyseur standard. L'une des raisons est qu'avec l'utilisation de champs structurés, il existe un mécanisme d'extension intégré. Vous devez vous assurer que lorsqu'un nouveau paramètre apparaît, votre application ne se bloque pas soudainement.

Vous souhaiterez peut-être également définir et utiliser vos propres en-têtes HTTP. Le format de champs structurés est un très bon « choix par défaut » qui supprime les décisions telles que « Comment dois-je encoder un objet de valeur clé » ou « Comment encoder une chaîne UTF-8 ».

Avec l'apparition d'analyseurs pour chaque langue, vous n'avez pas à vous soucier d'écrire vos propres formats uniques.

Paquet Javascript

Je suis le responsable d'une bibliothèque Javascript pour les champs structurés, appelée "en-têtes structurés", que j'ai également mise à jour pour cette nouvelle RFC. J'aurais aimé choisir le nom « champs structurés », mais j'ai choisi le nom avant que la norme d'origine ne change son nom.

Je viens de publier la v2 de cette bibliothèque prenant en charge ces nouveaux types, et j'ai également ajouté la prise en charge des modules ES.

Des commentaires ?

Répondez à l'un de ces éléments :

• [Post Mastodonte][4]
• [Message Bluesky][5]

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!