¿Tipo de mimo YAML?


112

¿Cuál es el tipo MIME más apropiado para usar al enviar datos estructurados con YAML a través de HTTP?

Se agradecería mucho una explicación de por qué una opción determinada es la más apropiada.

No hay ningún tipo de aplicación registrado o tipo de texto que pueda ver.

Ejemplo:

> GET /example.yaml

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

Posibles opciones:

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

Respuestas:


64

Ruby on Rails se utiliza application/x-yamlcon una alternativa de text/yaml( fuente ).

Creo que es solo una cuestión de convención, no hay un por qué técnico , hasta donde yo sé.


78
Esto no es del todo cierto. Los tipos de mímica que comienzan con text/deben procesarse como ISO-8859-1 a menos que se declare explícitamente otro tipo de mímica (por ejemplo text/html; charset=utf-8). Los tipos de application/mime que comienzan con se procesan como UTF-8 a menos que se declare explícitamente otro tipo de mime. Por ejemplo, text/x-yamlno puede usar caracteres UTF-8 mientras text/x-yaml; charset=utf-8y application/x-yamlpuede. IIRC, esto se define en RFC 3023.
Ryan Parman

2
@RyanParman Estás confundiendo un poco el conjunto de caracteres y el tipo MIME. Tienes razón en que text/*, sin un charset=parámetro explícito , se presume que es ISO-8859-1, pero las cosas en application/*no son necesariamente texto. (El RFC que vinculó es sobre XML, no estoy seguro de cómo es relevante).
Thanatos

3
@RyanParman No es cierto. tools.ietf.org/html/rfc6838#section-4.2.1 dice: 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.. No existe una definición formal de text/yamlni text/x-yaml, por lo que el valor predeterminado es UTF-8.
aef

7
RFC 3023, incluido el manejo de codificación, quedó obsoleto en 2014 por tools.ietf.org/html/rfc7303#section-3 . La regla predeterminada US-ASCII(nota: no ISO-8859-1) para text/*los tipos de medios en RFC 2046 ha quedado obsoleta 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.en tools.ietf.org/html/rfc6838#section-4.2.1 en enero de 2013. Ni RFC 3023 ni RFC 7303 dicen nada genérico sobre text/*HASTA DONDE SE.
aef

6
@RyanParman Entonces, su conclusión probablemente fue correcta en ese entonces, pero hizo referencia erróneamente a RFC 3023, mientras que la regla provino de RFC 2046. Sin embargo, hoy UTF-8es el valor predeterminado para cada text/*tipo de medio que no indica algo diferente en su registro de IANA.
aef

22

Aunque se aceptó otra respuesta, consulte este Registro de tipo de medio propuesto para el hilo YAML en la lista de correo de la IANA para revisar el Tipo de medio en el que Ben Harris, Servicios de Información de la Universidad de Cambridge, propuso en julio de 2015 en nombre del equipo de YAML el tipo de medio :

text/vnd.yaml

con alias (sugeridos) obsoletos:

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

Eso todavía está propuesto / pendiente (el hilo no indica el estado de la propuesta) por lo que esta respuesta no es más definitiva que las otras :-)


11
Parece que la propuesta no llegó a ninguna parte a partir de enero de 2018, y mis intentos de contactar al autor no han
recibido

15

Yo diría text / x-yaml:

texto sobre aplicación porque es legible por humanos

x-yaml sobre yaml porque no se ha aceptado en la lista registrada de tipos de mime.

Editar: de RFC 3023 (Tipos de medios XML):

El tipo de medio de nivel superior "texto" tiene algunas restricciones en las entidades MIME y se describen en [RFC2045] y [RFC2046]. En particular, la familia UTF-16, UCS-4 y UTF-32 no están permitidas (excepto a través de HTTP [RFC2616], que usa un mecanismo similar a MIME).

Interesante ... No estoy exactamente seguro de lo que significa, pero hay que pensar.


1
Es legible por humanos, pero su intención es comunicar aplicaciones ... XML está en aplicación
Vinko Vrsalovic

Y también bajo texto. Parece que tendrías que tener tanto texto / x-yaml como application / x-yaml ... rfc-editor.org/rfc/rfc3023.txt
Vinko Vrsalovic

Por lo que vale, esto es lo que entiende la implementación TastyPie REST de Django.
Michael Scheper

1
... pero ¿JSON también es legible por humanos? Creo que sería más coherente decir application/yaml, como podríamos decir application/jsony applicaiton/xml.
Anthony Rutledge

7

Se desaconsejan los tipos de medios "x-", consulte RFC 4288, Sección 3.4 . Lo correcto es utilizar el árbol personal, el árbol de proveedores o intentar realmente un registro de tipo de medio adecuado.


Entonces eso sería application/vnd.yamlo text/vnd.yaml(el texto parece mejor)
cables

No es del todo cierto también. El único árbol de subtipos que está diseñado para su uso sin registro en IANA es x.. vnd.y prs.requiere registro. Consulte tools.ietf.org/html/rfc6838#section-3.2 y tools.ietf.org/html/rfc6838#section-3.3 .
aef


2

En Chrome application/yamlse descargará, mientras que text/yamlse mostrará.


Esto no proporciona una respuesta a la pregunta. Una vez que tenga suficiente reputación , podrá comentar en cualquier publicación ; en su lugar, proporcione respuestas que no requieran aclaración por parte del autor de la pregunta . - De la opinión
ysf

1
@ysf Su comentario es excesivamente pedante, en mi opinión. La publicación es breve pero acumulada, responde la pregunta del OP, explica el "por qué" de cada opción y se esfuerza por establecer sus limitaciones ("... al menos en Chrome esto es cierto"). Sin mencionar: nadie más proporcionó esta informacion. Es posible que el OP ni siquiera haya considerado que diferentes tipos de contenido podrían dar lugar a diferentes comportamientos, que en realidad pueden ser útiles para él o ella.
Dan H
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.