Api-blueprint: Prise en charge de plusieurs en-têtes HTTP

Créé le 26 juil. 2016 · 3Commentaires · Source: apiaryio/api-blueprint

Il semble que l'API Blueprint n'autorise pas plusieurs en-têtes HTTP.

Selon l'ancienne RFC 2616, il est possible d'avoir plusieurs en-têtes HTTP. RFC 7230 le rend plus clair :

   A sender MUST NOT generate multiple header fields with the same field
   name in a message unless either the entire field value for that
   header field is defined as a comma-separated list [i.e., #(values)]
   or the header field is a well-known exception (as noted below).

Des éléments tels que les en-têtes Prefer et Link sont souvent présentés sur des lignes individuelles pour plus de lisibilité.

L'API Blueprint exige actuellement que vous les présentiez sur une seule ligne sous forme de liste séparée par des virgules (ce qui est assez bien), mais la rendre plus lisible en permettant de les écrire sur des lignes séparées serait l'idéal.

Merci!
:haut-de-forme:

Language Confirmed Bug

Source

BigBlueHat

Tous les 3 commentaires

Pour être complet, les en-têtes Set-Cookie et Link sont "tolérés" par l'analyseur. La question est de savoir si :

Conserver la liste blanche des en-têtes pouvant apparaître plusieurs fois
Supprimer complètement cet avertissement

On dirait que moi et @BigBlueHat sommes

zdne le 26 juil. 2016

👍1

Notes sur la mise en œuvre actuelle https://github.com/apiaryio/snowcrash/issues/75#issuecomment -58886108

zdne le 26 juil. 2016

La suppression de l'avertissement a l'avantage de permettre aux utilisateurs de créer leurs propres en-têtes personnalisés qui pourraient potentiellement être définis comme ayant des valeurs de liste séparées par des virgules. Difficile de connaître l'avenir, alors "soyez libéral dans ce que vous acceptez des autres". :le sourire:

BigBlueHat le 26 juil. 2016

👍1

Cette page vous a été utile?

0 / 5 - 0 notes