Typ mime YAML?

112

Jaki jest najbardziej odpowiedni typ MIME do użycia podczas wysyłania danych strukturalnych z YAML przez HTTP?

Bardzo mile widziane byłoby wyjaśnienie, dlaczego dany wybór jest najbardziej odpowiedni.

Nie widzę żadnego zarejestrowanego typu aplikacji ani typu tekstu .

Przykład:

> GET /example.yaml

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

Możliwe opcje:

text/yaml
text/x-yaml
application/yaml
application/x-yaml
http mime mime-types yaml Jon Cram
źródło

Odpowiedzi:

64

Ruby on Rails używa application/x-yamlz alternatywą text/yaml( źródło ).

Myślę, że to tylko kwestia konwencji , o ile wiem , nie ma technicznego powodu .

Vinko Vrsalovic
źródło
79
To nie jest do końca prawdą. Typy Mime rozpoczynające się od text/mają być przetwarzane jako ISO-8859-1, chyba że jawnie zadeklarowano inny typ MIME (np text/html; charset=utf-8.). Typy MIME rozpoczynające się od application/są przetwarzane jako UTF-8, chyba że jawnie zadeklarowano inny typ MIME. Na przykład text/x-yamlnie można używać znaków UTF-8 podczas text/x-yaml; charset=utf-8i application/x-yamlmożna. IIRC, jest to zdefiniowane w RFC 3023.
Ryan Parman
2
@RyanParman Trochę mylisz zestaw znaków i typ MIME. Masz rację text/*, bez wyraźnego charset=parametru zakłada się, że jest to ISO-8859-1, ale rzeczy application/*nie muszą być tekstem. (Podlinkowany dokument RFC dotyczy języka XML, nie wiem, jak jest on istotny.)
Thanatos,
3
@RyanParman Nie prawda. tools.ietf.org/html/rfc6838#section-4.2.1 mówi: 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.. Nie ma formalnej definicji text/yamlnor text/x-yaml, więc domyślnym jest UTF-8.
aef
7
RFC 3023, w tym obsługa kodowania, została przestarzała w 2014 r. Przez tools.ietf.org/html/rfc7303#section-3 . Reguła domyślna US-ASCII(uwaga: nie ISO-8859-1) dla text/*typów mediów w RFC 2046 została przestarzała 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.w tools.ietf.org/html/rfc6838#section-4.2.1 w styczniu 2013 r. Ani RFC 3023 ani RFC 7303 nie mówią nic ogólnego na temat text/*AFAIK.
aef
6
@RyanParman Twój wniosek był prawdopodobnie wtedy poprawny, ale omyłkowo odwołałeś się do RFC 3023, podczas gdy reguła pochodzi z RFC 2046. Jednak dzisiaj UTF-8jest domyślna dla każdego text/*typu mediów, który nie stwierdza czegoś innego w swojej rejestracji IANA.
aef
22

Chociaż inna odpowiedź została zaakceptowana, proszę odnieść się do tej Proponowanej rejestracji typu mediów dla wątku YAML na liście mailingowej IANA w celu przejrzenia typu mediów, w którym Ben Harris z University of Cambridge Information Services zaproponował w lipcu 2015 r. W imieniu zespołu YAML rodzaj mediów :

text/vnd.yaml

z (sugerowanymi) przestarzałymi aliasami:

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

To jest nadal proponowane / oczekujące (wątek nie wskazuje statusu wniosku), więc ta odpowiedź nie jest bardziej ostateczna niż pozostałe :-)

djb
źródło
11
Wygląda na to, że propozycja zniknęła donikąd od stycznia 2018 r., A moje próby skontaktowania się z autorem pozostały bez odpowiedzi
djb
15

Powiedziałbym tekst / x-yaml:

tekst na aplikacji, ponieważ jest czytelny dla człowieka

x-yaml zamiast yaml, ponieważ nie został zaakceptowany na zarejestrowanej liście typów MIME.

Edycja: z RFC 3023 (XML Media Types):

Typ mediów najwyższego poziomu „tekst” ma pewne ograniczenia dotyczące jednostek MIME i są one opisane w [RFC2045] i [RFC2046]. W szczególności rodziny UTF-16, UCS-4 i UTF-32 są niedozwolone (z wyjątkiem protokołu HTTP [RFC2616], który wykorzystuje mechanizm podobny do MIME).

Ciekawe ... Nie do końca wiem, co to znaczy, ale do przemyślenia.

Greg
źródło
1
Jest czytelny dla człowieka, ale jego celem jest przekazywanie aplikacji ... XML jest w aplikacji
Vinko Vrsalovic
A także pod tekstem. Wygląda na to, że musisz mieć zarówno tekst / x-yaml, jak i aplikację / x-yaml ... rfc-editor.org/rfc/rfc3023.txt
Vinko Vrsalovic
To jest warte tego, co rozumie implementacja TastyPie REST w Django.
Michael Scheper
1
... ale czy JSON nie jest też czytelny dla człowieka? Myślę, że bardziej spójne byłoby powiedzenie application/yaml, tak jak moglibyśmy powiedzieć application/jsoni applicaiton/xml.
Anthony Rutledge
7

Nośniki typu „x-” są odradzane, zobacz RFC 4288, sekcja 3.4 . Właściwe jest użycie drzewa osobistego, drzewa dostawców lub faktycznie próba zarejestrowania odpowiedniego typu nośnika.

Julian Reschke
źródło
Tak że byłoby application/vnd.yamlalbo text/vnd.yaml(tekst wydaje się lepszy)
przewody
Również nie do końca prawda. Jedynym drzewem podtypu, które jest przeznaczone do użytku bez rejestracji w IANA, jest x.. vnd.i prs.wymagają rejestracji. Zobacz tools.ietf.org/html/rfc6838#section-3.2 i tools.ietf.org/html/rfc6838#section-3.3 .
aef
3

W Chrome application/yamlpobierze się, a text/yamlwyświetli się.

Giulio
źródło
To nie daje odpowiedzi na pytanie. Gdy zdobędziesz wystarczającą reputację , będziesz mógł komentować każdy post ; zamiast tego udziel odpowiedzi, które nie wymagają wyjaśnień od pytającego . - Z recenzji
ysf
2
@ysf Twój komentarz jest nadmiernie pedantyczny, IMO. Wpis jest krótki, ale zawiera odpowiedzi na pytanie OP, wyjaśnia „dlaczego” każdej opcji i stara się określić jej ograniczenia („… przynajmniej w Chrome to prawda”.) Nie wspominając: nikt inny nie podał ta informacja. OP mógł nawet nie wziąć pod uwagę, że różne typy treści mogą skutkować różnymi zachowaniami, które w rzeczywistości mogą być dla niego przydatne.
Dan H