Type de mime YAML?

112

Quel est le type MIME le plus approprié à utiliser lors de l'envoi de données structurées avec YAML sur HTTP?

Une explication des raisons pour lesquelles un choix donné est le plus approprié serait très appréciée.

Il n'y a pas de type d'application ou de type de texte enregistré que je peux voir.

Exemple:

> GET /example.yaml

< Content-Type: ????
<
< --- # Favorite movies
< - Casablanca
< - North by Northwest
< - Notorious

Options possibles:

text/yaml
text/x-yaml
application/yaml
application/x-yaml
http mime mime-types yaml Jon Cram
la source

Réponses:

64

Ruby on Rails utilise application/x-yamlavec une alternative de text/yaml( source ).

Je pense que c'est juste une question de convention, il n'y a pas de pourquoi technique , pour autant que je sache.

Vinko Vrsalovic
la source
79
Ce n'est pas tout à fait vrai. Les types Mime commençant par text/doivent être traités comme ISO-8859-1 à moins qu'un autre type Mime ne soit explicitement déclaré (par exemple text/html; charset=utf-8). Les types Mime commençant par application/sont traités comme UTF-8 à moins qu'un autre type Mime ne soit explicitement déclaré. Par exemple, text/x-yamlne peut pas utiliser les caractères UTF-8 tant que text/x-yaml; charset=utf-8et application/x-yamlpeut. IIRC, ceci est défini dans la RFC 3023.
Ryan Parman
2
@RyanParman Vous confondez un peu le jeu de caractères et le type MIME. Vous avez raison de dire que text/*, sans charset=paramètre explicite , il est présumé être ISO-8859-1, mais les éléments application/*ne sont pas nécessairement du texte. (Le RFC que vous avez lié concerne XML, je ne sais pas comment il est pertinent.)
Thanatos
3
@RyanParman Pas vrai. tools.ietf.org/html/rfc6838#section-4.2.1 dit: If a "charset" parameter is specified, it SHOULD be a required parameter, eliminating the options of specifying a default value. If there is a strong reason for the parameter to be optional despite this advice, each subtype MAY specify its own default value, or alternatively, it MAY specify that there is no default value. Finally, the "UTF-8" charset [RFC3629] SHOULD be selected as the default.. Il n'y a pas de définition formelle de text/yamlni text/x-yaml, donc la valeur par défaut est UTF-8.
aef
7
La RFC 3023, y compris la gestion de l'encodage, est devenue obsolète en 2014 par tools.ietf.org/html/rfc7303#section-3 . La règle par défaut US-ASCII(note: non ISO-8859-1) pour text/*les types de média dans la RFC 2046 a été obsolète par Regardless of what approach is chosen, all new text/* registrations MUST clearly specify how the charset is determined; relying on the US-ASCII default defined in Section 4.1.2 of [RFC2046] is no longer permitted.dans tools.ietf.org/html/rfc6838#section-4.2.1 en janvier 2013. Ni la RFC 3023 ni la RFC 7303 ne disent quoi que ce soit de générique sur text/*AUTANT QUE JE SACHE.
aef
6
@RyanParman Donc, votre conclusion était probablement correcte à l'époque, mais vous avez fait référence par erreur à la RFC 3023, alors que la règle venait de la RFC 2046. Aujourd'hui, cependant, UTF-8c'est la valeur par défaut pour chaque text/*type de média qui n'indique rien de différent dans son enregistrement IANA.
aef
22

Bien qu'une autre réponse ait été acceptée, veuillez vous référer à cette proposition d'enregistrement du type de média pour le fil YAML sur la liste de diffusion IANA pour examiner le type de média dans lequel Ben Harris, University of Cambridge Information Services, a proposé en juillet 2015 au nom de l'équipe YAML le type de média :

text/vnd.yaml

avec des alias obsolètes (suggérés):

text/yaml
text/x-yaml
application/x-yaml

C'est toujours proposé / en attente (le fil n'indique pas le statut de la proposition) donc cette réponse n'est pas plus définitive que les autres :-)

djb
la source
11
Il semble que cette proposition
n'ait
15

Je dirais text / x-yaml:

texte au-dessus de l'application car il est lisible par l'homme

x-yaml sur yaml car il n'a pas été accepté dans la liste enregistrée des types mime.

Edit: à partir de RFC 3023 (XML Media Types):

Le type de support de niveau supérieur "texte" a certaines restrictions sur les entités MIME et ils sont décrits dans [RFC2045] et [RFC2046]. En particulier, la famille UTF-16, UCS-4 et UTF-32 ne sont pas autorisées (sauf sur HTTP [RFC2616], qui utilise un mécanisme de type MIME).

Intéressant ... Je ne sais pas exactement ce que cela signifie, mais matière à réflexion.

Greg
la source
1
Il est lisible par l'homme mais son intention est de communiquer des applications ... XML est en cours d'application
Vinko Vrsalovic
Et aussi sous texte. Il semble que vous deviez avoir à la fois text / x-yaml et application / x-yaml ... rfc-editor.org/rfc/rfc3023.txt
Vinko Vrsalovic
Pour ce que ça vaut, c'est ce que comprend l'implémentation TastyPie REST de Django.
Michael Scheper
1
... mais JSON n'est-il pas également lisible par l'homme? Je pense qu'il serait plus cohérent de dire application/yaml, comme on pourrait dire application/jsonet applicaiton/xml.
Anthony Rutledge
7

Les types de supports "x-" sont déconseillés, voir RFC 4288, section 3.4 . La bonne chose à faire est d'utiliser l'arborescence personnelle, l'arborescence des fournisseurs ou de tenter un enregistrement approprié du type de support.

Julian Reschke
la source
Donc ce serait application/vnd.yamlou text/vnd.yaml(le texte semble meilleur)
fils
Pas tout à fait vrai aussi. Le seul arbre de sous-types destiné à être utilisé sans enregistrement auprès de l'IANA est x.. vnd.et prs.nécessitent une inscription. Voir tools.ietf.org/html/rfc6838#section-3.2 et tools.ietf.org/html/rfc6838#section-3.3 .
aef
3

Sur Chrome application/yamlva télécharger, tandis que text/yamls'affiche.

Giulio
la source
Cela ne répond pas à la question. Une fois que vous aurez une réputation suffisante, vous pourrez commenter n'importe quel message ; au lieu de cela, fournissez des réponses qui ne nécessitent pas de clarification de la part du demandeur . - De l'avis
ysf
2
@ysf Votre commentaire est excessivement pédant, OMI. Le message est bref mais accumulé, répond à la question du PO, explique le "pourquoi" de chaque option, ET s'efforce de préciser ses limites ("... au moins sur Chrome c'est vrai".) Sans oublier: personne d'autre n'a fourni cette information. Le PO n'a peut-être même pas considéré que différents types de contenu pouvaient entraîner des comportements différents, ce qui pourrait lui être utile.
Dan H