Тип пантомимы YAML?

113

Какой тип MIME лучше всего использовать при отправке данных, структурированных с помощью YAML, через HTTP?

Было бы очень полезно объяснить, почему данный выбор является наиболее подходящим.

Я не вижу зарегистрированного типа приложения или текстового типа .

Пример:

> GET /example.yaml

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

Возможные варианты:

text/yaml
text/x-yaml
application/yaml
application/x-yaml
http mime mime-types yaml Джон Крам
источник

Ответы:

64

Ruby on Rails использует application/x-yamlальтернативу text/yaml( источник ).

Я думаю, что это всего лишь вопрос условности, насколько я могу судить , нет никаких технических причин.

Винко Врсалович
источник
80
Это не совсем так. Типы MIME, которые начинаются с text/, должны обрабатываться как ISO-8859-1, если явно не объявлен другой тип MIME (например, text/html; charset=utf-8). Типы application/MIME , начинающиеся с , обрабатываются как UTF-8, если явно не объявлен другой тип MIME. Например, text/x-yamlпока нельзя использовать символы UTF-8, text/x-yaml; charset=utf-8а application/x-yamlможно. IIRC, это определено в RFC 3023.
Райан Парман,
2
@RyanParman Вы немного путаете набор символов и тип MIME. Вы правы, что text/*без явного charset=параметра предполагается ISO-8859-1, но application/*это не обязательно текст. (RFC, на который вы ссылаетесь, касается XML, не знаю, насколько он актуален.)
Танатос
3
@RyanParman Неправда. tools.ietf.org/html/rfc6838#section-4.2.1 говорит: 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.. Формального определения text/yamlни нет text/x-yaml, поэтому по умолчанию используется UTF-8.
aef
7
RFC 3023, включая обработку кодирования, был отменен в 2014 году на tools.ietf.org/html/rfc7303#section-3 . Правило по умолчанию для US-ASCII(примечание: не ISO-8859-1) для text/*типов носителей в RFC 2046 устарела, 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.в tools.ietf.org/html/rfc6838#section-4.2.1 в январе 2013 г. Ни RFC 3023 , ни RFC 7303 говорят ничего общего о text/*НАСКОЛЬКО МНЕ ИЗВЕСТНО.
aef
6
@RyanParman Итак, ваш вывод, вероятно, тогда был правильным, но вы ошибочно сослались на RFC 3023, в то время как правило пришло из RFC 2046. Однако сегодня UTF-8оно используется по умолчанию для каждого text/*типа носителя, который не указывает что-то другое в своей регистрации IANA.
aef
22

Хотя был принят другой ответ, обратитесь к этой Предложенной регистрации типа носителя для ветки YAML в списке рассылки IANA, чтобы просмотреть Тип носителя, в котором Бен Харрис из Информационной службы Кембриджского университета предложил в июле 2015 года от имени группы YAML тип носителя. :

text/vnd.yaml

с (предлагаемыми) устаревшими псевдонимами:

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

Это все еще предлагается / ожидает рассмотрения (ветка не указывает статус предложения), поэтому этот ответ не более окончательный, чем другие :-)

DJB
источник
11
Похоже, это предложение никуда не делось по состоянию на январь 2018 года, и мои попытки связаться с автором остались без ответа
djb 04
15

Я бы сказал text / x-yaml:

текст поверх приложения, потому что он удобочитаемый

x-yaml вместо yaml, потому что он не был принят в зарегистрированный список типов mime.

Изменить: из RFC 3023 (типы носителей XML):

Медиа-тип верхнего уровня «текст» имеет некоторые ограничения на объекты MIME, и они описаны в [RFC2045] и [RFC2046]. В частности, семейство UTF-16, UCS-4 и UTF-32 не разрешены (кроме протокола HTTP [RFC2616], который использует механизм, подобный MIME).

Интересно ... Не совсем понимаю, что это значит, но пища для размышлений.

Greg
источник
1
Он удобочитаем, но его цель - обмениваться данными между приложениями ... XML находится в разработке
Винко Врсалович 01
А также под текстом. Похоже, вам понадобятся и text / x-yaml, и application / x-yaml ... rfc-editor.org/rfc/rfc3023.txt
Винко Врсалович 01
Как бы то ни было, это то, что понимает реализация Django TastyPie REST.
Майкл Шепер 03
1
... но разве JSON тоже не читается человеком? Я думаю, было бы более последовательным сказать application/yaml, как мы могли бы сказать application/jsonи applicaiton/xml.
Энтони Ратледж
7

Типы носителей "x-" не приветствуются, см. RFC 4288, раздел 3.4 . Правильнее всего будет использовать личное дерево, дерево поставщиков или действительно попытаться правильно зарегистрировать тип носителя.

Джулиан Решке
источник
Так что было бы application/vnd.yamlили text/vnd.yaml(текст кажется лучше)
провода
1
Не совсем так. Единственное дерево подтипов, которое предназначено для использования без регистрации в IANA, - это x.. vnd.и prs.требуют регистрации. См. Tools.ietf.org/html/rfc6838#section-3.2 и tools.ietf.org/html/rfc6838#section-3.3 .
aef
4

В Chrome application/yamlзагрузится, пока text/yamlбудет отображаться.

Джулио
источник
Это не дает ответа на вопрос. Как только у вас будет достаточная репутация, вы сможете комментировать любой пост ; вместо этого предоставьте ответы, которые не требуют пояснений от спрашивающего . - Из
отзыва
3
@ysf Ваш комментарий излишне педантичен, IMO. Сообщение краткое, но подробное, отвечает на вопрос OP, объясняет «почему» каждого параметра И пытается указать его ограничения («... по крайней мере, в Chrome это правда».) Не говоря уже о том, что никто другой не предоставил эта информация. OP, возможно, даже не учел, что разные типы контента могут приводить к разному поведению, которое на самом деле может быть полезно для него или нее.
Дэн Х,