YAML Pantomime Typ?

111

Welcher MIME-Typ eignet sich am besten zum Senden von mit YAML strukturierten Daten über HTTP?

Eine Erklärung, warum eine bestimmte Wahl am besten geeignet ist, wäre sehr willkommen.

Es gibt keinen registrierten Anwendungstyp oder Texttyp , den ich sehen kann.

Beispiel:

> GET /example.yaml

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

Möglichkeiten:

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

— Jon Cram
quelle

63

Ruby on Rails verwendet application/x-yamlmit einer Alternative von text/yaml( Quelle ).

Ich denke, es ist nur eine Frage der Konvention, es gibt kein technisches Warum, soweit ich das beurteilen kann.

— Vinko Vrsalovic
quelle

77

Das ist nicht ganz richtig. MIME-Typen, die mit beginnen, text/sind als ISO-8859-1 zu verarbeiten, sofern nicht ausdrücklich ein anderer MIME-Typ deklariert ist (z text/html; charset=utf-8. B. ). MIME-Typen, die mit beginnen, application/werden als UTF-8 verarbeitet, sofern nicht ausdrücklich ein anderer MIME-Typ deklariert ist. Beispielsweise text/x-yamlkönnen UTF-8-Zeichen während text/x-yaml; charset=utf-8und nicht application/x-yamlverwendet werden. IIRC, dies ist in RFC 3023 definiert.

— Ryan Parman

2

@ RyanParman Du verwirrst Zeichensatz und MIME-Typ ein bisschen. Sie haben Recht, dass text/*ohne einen expliziten charset=Parameter ISO-8859-1 angenommen wird, aber die Dinge in application/*sind nicht unbedingt Text. (Der von Ihnen verknüpfte RFC handelt von XML, nicht sicher, wie relevant er ist.)

— Thanatos

3

@ RyanParman Nicht wahr. tools.ietf.org/html/rfc6838#section-4.2.1 sagt :

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.

. Es gibt keine formale Definition von text/yamlnoch text/x-yaml, daher ist die Standardeinstellung UTF-8.

— Aef

7

RFC 3023, einschließlich der Codierungsbehandlung, wurde 2014 von tools.ietf.org/html/rfc7303#section-3 überholt . Die Standardregel US-ASCII(Anmerkung: nicht ISO-8859-1) für text/*Medientypen in RFC 2046 wurde im Januar 2013

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.

in tools.ietf.org/html/rfc6838#section-4.2.1 überholt . Weder RFC 3023 noch RFC 7303 sagen etwas Allgemeines aus text/*SO VIEL ICH WEISS.

— Aef

6

@RyanParman Ihre Schlussfolgerung war damals wahrscheinlich richtig, aber Sie haben fälschlicherweise auf RFC 3023 verwiesen, während die Regel aus RFC 2046 stammte. Heute ist dies jedoch UTF-8die Standardeinstellung für jeden text/*Medientyp, der in seiner IANA-Registrierung nichts anderes angibt.

— Aef

21

Obwohl eine andere Antwort akzeptiert wurde, finden Sie in diese Vorgeschlagen Medientyp Registrierung für YAML Thread auf der Mailingliste der IANA für die Überprüfung des Medientypen , in dem Ben Harris, University of Cambridge Information Services, vorgeschlagen der Medientyp im Juli 2015 im Namen des YAML - Teams ::

text/vnd.yaml

mit (vorgeschlagenen) veralteten Aliasnamen:

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

Das ist noch vorgeschlagen / ausstehend (der Thread zeigt nicht den Status des Vorschlags an), daher ist diese Antwort nicht definitiver als die anderen :-)

— djb
quelle

11

Es scheint, dass der Vorschlag ab Januar 2018 nirgendwo hingegangen ist und meine Versuche, den Autor zu kontaktieren, unbeantwortet geblieben sind

— djb

15

Ich würde text / x-yaml sagen:

Text über Anwendung, weil es für Menschen lesbar ist

x-yaml über yaml, da es nicht in die registrierte Liste der MIME-Typen aufgenommen wurde.

Bearbeiten: aus RFC 3023 (XML-Medientypen):

Der Medientyp "Text" der obersten Ebene unterliegt einigen Einschränkungen für MIME-Entitäten und wird in [RFC2045] und [RFC2046] beschrieben. Insbesondere die UTF-16-Familie, UCS-4 und UTF-32 sind nicht zulässig (außer über HTTP [RFC2616], das einen MIME-ähnlichen Mechanismus verwendet).

Interessant ... Nicht ganz sicher, was es bedeutet, aber Denkanstöße.

— Greg
quelle

1

Es ist für Menschen lesbar, aber seine Absicht ist es, Anwendungen zu kommunizieren ... XML ist in Anwendung

— Vinko Vrsalovic

Und auch unter Text. Es scheint, dass Sie sowohl Text / x-yaml als auch application / x-yaml haben müssen ... rfc-editor.org/rfc/rfc3023.txt

— Vinko Vrsalovic

Für das, was es wert ist, versteht Djangos TastyPie REST-Implementierung dies.

— Michael Scheper

1

... aber ist JSON nicht auch für Menschen lesbar? Ich denke, es wäre konsequenter zu sagen application/yaml, genau wie wir sagen könnten application/jsonund applicaiton/xml.

— Anthony Rutledge

7

Von "x-" Medientypen wird abgeraten, siehe RFC 4288, Abschnitt 3.4 . Das Richtige ist, den persönlichen Baum oder den Lieferantenbaum zu verwenden oder tatsächlich eine ordnungsgemäße Registrierung des Medientyps zu versuchen.

— Julian Reschke
quelle

Also das wäre application/vnd.yamloder text/vnd.yaml(Text scheint besser zu sein)

— Drähte

Nicht ganz richtig. Der einzige Subtypbaum, der ohne Registrierung bei IANA verwendet werden soll, ist x.. vnd.und prs.Registrierung erforderlich. Siehe tools.ietf.org/html/rfc6838#section-3.2 und tools.ietf.org/html/rfc6838#section-3.3 .

— Aef

1

Wie pro MIME - Typ Liste ist es text/yaml, auch wenn es nicht in der offiziellen IANA MIME - Liste

— Der Pate
quelle

1

Auf Chrome application/yamlwird heruntergeladen, während text/yamlangezeigt wird.

— Giulio
quelle

Dies gibt keine Antwort auf die Frage. Sobald Sie einen ausreichenden Ruf haben, können Sie jeden Beitrag kommentieren . Geben Sie stattdessen Antworten, die nicht vom Fragesteller geklärt werden müssen . - Aus dem Review

— ysf

1

@ysf Dein Kommentar ist übermäßig pedantisch, IMO. Der Beitrag ist kurz, aber genau, beantwortet die Frage des OP, erklärt das "Warum" jeder Option UND bemüht sich, ihre Einschränkungen anzugeben ("... zumindest bei Chrome ist dies wahr"). Ganz zu schweigen davon, dass niemand anderes angegeben hat diese Information. Das OP hat möglicherweise nicht einmal berücksichtigt, dass unterschiedliche Inhaltstypen zu unterschiedlichen Verhaltensweisen führen können, die für ihn oder sie tatsächlich nützlich sein können.

— Dan H