YAML tipo mime?

Qual è il più appropriato, tipo MIME da utilizzare per l’invio di dati strutturati con YAML tramite HTTP?

Una spiegazione di perché una scelta più appropriata sarebbe molto apprezzato.

Non è stato registrato alcun tipo di applicazione o tipo di testo che posso vedere.

Esempio:

> GET /example.yaml

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

Opzioni possibili:

text/yaml
text/x-yaml
application/yaml
application/x-yaml
InformationsquelleAutor Jon Cram | 2008-12-01

 

4 Replies
  1. 58

    Ruby on Rails usa application/x-yaml con un’alternativa di text/yaml (fonte).

    Penso sia solo una questione di convenzione, non c’è tecnico perché, per quanto posso dire.

    • Strano, google per “yaml mime” dà un rubino collegamento con il primo colpo, con text/x-yaml e non c’è menzione di application/x-yaml
    • Questo non è molto vero. Tipi Mime che iniziano con text/ sono trattati come ISO-8859-1, a meno che un altro tipo mime è dichiarato in modo esplicito (ad esempio text/html; charset=utf-8). Tipi Mime che iniziano con application/ sono trattati come UTF-8, a meno che un altro tipo mime è dichiarato in modo esplicito. Per esempio, text/x-yaml non è possibile utilizzare caratteri UTF-8, mentre text/x-yaml; charset=utf-8 e application/x-yaml possibile. IIRC, questo è definito nella RFC 3023.
    • Grazie, ottima info. Non si applica a YAML? Non è XML…
    • Sei confusa set di caratteri e il tipo MIME un po’. Hai ragione che text/*, senza un esplicito charset= parametro si presume essere ISO-8859-1, ma le cose in application/* non sono necessariamente di testo. (RFC si è collegato su XML, non so come si è rilevante.)
    • Non è vero. 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.. Non c’è definizione formale di text/yamltext/x-yaml, in modo che il valore di default è UTF-8.
    • Hai ragione. Ho capito, ma non sono riuscito a spiegare che adeguatamente.
    • So che la RFC 3023 è su XML, ma io avevo capito che tutti i tipi di file sotto il “testo” tipo mime gruppo erano implicitamente considerato come ISO-8859-1. Lo stesso vale per text/plain text/javascript. La mia impressione è stata che anche applicato al testo/yaml come bene.
    • RFC 3023, tra cui la codifica di gestione è stato reso obsoleto nel 2014 da tools.ietf.org/html/rfc7303#section-3. La regola di default per US-ASCII (nota: non ISO-8859-1) per text/* tipi di supporto RFC 2046 è stato reso obsoleto da 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 nel mese di gennaio 2013. Né RFC 3023 né RFC 7303 dire qualcosa di generico su text/* AFAIK.
    • Quindi la tua conclusione è probabilmente corretto, allora, ma per errore di riferimento RFC 3023, mentre la regola è venuto da RFC 2046. Oggi, però, UTF-8 è il valore predefinito per ogni text/* tipo di supporto che non è stato qualcosa di diverso nella sua IANA di registrazione.

  2. 18

    Anche se un’altra risposta, che è stata accettata, si prega di fare riferimento a questo Proposto tipo di supporto di registrazione per YAML thread su IANA mailing list per la revisione del Tipo di Supporto che Ben Harris, Università di Cambridge, Servizi di Informazione, proposto nel mese di luglio 2015 per conto di YAML team il tipo di supporto:

    text/vnd.yaml
    

    con (suggerito) obsoleto alias:

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

    Che viene ancora proposta/in sospeso (il thread non indicano lo stato della proposta), in modo che questa risposta è no più accentuato rispetto agli altri 🙂

    • Sembra che la sua proposta è andato da nessuna parte, a gennaio 2018, e i miei tentativi di contattare l’autore sono andati senza risposta
  3. 14

    Direi text/x-yaml:

    testo su applicazione perché è un formato leggibile

    x-yaml oltre yaml, perché non è stato accettato nel registrato elenco di tipi mime.

    Modifica: da RFC 3023 (XML Tipi di Media):

    Alto livello di supporto di tipo “testo” ha
    alcune restrizioni su MIME entità
    e sono descritti in [RFC2045]
    e [RFC2046]. In particolare, il
    UTF-16 famiglia, UCS-4, e UTF-32
    non è permesso (tranne su
    HTTP[RFC2616], che utilizza un MIME-come
    meccanismo).

    Interessante… Non esattamente sicuro di cosa significhi, ma il cibo per il pensiero.

    • E ‘ leggibile, ma il suo intento è quello di comunicare le applicazioni… XML è al di sotto di applicazione
    • E anche sotto il testo. Sembra che dovresti avere sia text/x-yaml e application/x-yaml… rfc-editor.org/rfc/rfc3023.txt
    • Per quel che vale, questo è quello di Django TastyPie RESTO attuazione capisce.
  4. 6

    “x-” tipi di supporto sono scoraggiati, vedere RFC 4288, Sezione 3.4. La cosa giusta da fare è utilizzare il personal albero, il venditore albero, o addirittura tentare un corretto tipo di supporto di registrazione.

Lascia un commento