RFC: 2068
Оригинал: Hypertext Transfer Protocol - HTTP/1.1
Другие версии: RFC 2616
Категория: Предложенный стандарт
Дата публикации:
Авторы: , , , ,
Перевод: Алексей Симонов

3.7.1. Канонизация и предопределенные значения типа text

Медиа типы Интернета зарегистрированы в канонической форме. Вообще, тело объекта, передаваемое HTTP сообщением, ДОЛЖНО быть представлено в соответствующей каноническиой форме до передачи; исключение составляют типы "text", определяемые в следующем абзаце.

В канонической форме медиа подтипы типа "text" используют CRLF в качестве метки конца строки. HTTP ослабляет это требование и позволяет передавать текст размеченный таким образом, что еденичные CR или LF могут быть метками конца строки, правда это правило должно быть выполнено для всего тела объекта (entity-body). HTTP приложения ДОЛЖНЫ воспринимать CRLF, просто CR, и просто LF как представление конца строки в текстовых типах, переданных по HTTP. Кроме того, если текст представляется в кодовой таблице, которая не использует октеты 13 и 10 для CR и LF соответственно, что имеет место в некоторых многобайтовых кодовых таблицах, то HTTP позволяет использовать любые последовательности октетов, определенные этим набором символов для представления эквивалентов CR и LF в качестве кода конца строки. Эта гибкость в отношении концов строк применима только к текстовым типам в теле объекта; просто CR или просто LF НЕ ДОЛЖНЫ заменять CRLF внутри любой управляющей структуры HTTP (типа поля заголовка и разделителей типа multipart).

Если тело объекта кодируется при помощи Content-Encoding, то основные данные ДОЛЖНЫ быть в определенной выше форме до кодирования.

Параметр "charset" используется с некоторыми медиа типами для указания кодовой таблицы (раздел 3.4), используемой для представления данных. Если параметр "charset" не указан отправителем, то при получении по HTTP медиа подтипы типа "text" имеют значение "charset", по умолчанию равное "ISO-8859-1". Данные в кодовых таблицах или их подмножествах, отличных от "ISO-8859-1" ДОЛЖНЫ быть помечены соответствующим значением "charset".

Некоторое программное обеспечение HTTP/1.0 интерпретировало заголовок Content-Type без параметра "charset" неправильно, как означающее "должен предположить получатель". Отправители, желающие предусмотреть такое поведение МОГУТ включать параметр "charset" даже когда charset равен ISO-8859-1 и ДОЛЖНЫ сделать это, если известно, что это не запутает получателя.

К сожалению, некоторые старые HTTP/1.0 клиенты не работали правильно с определением параметра "charset". HTTP/1.1 получатели ДОЛЖНЫ отдавать приоритет метке "charset", поставленной отправителем; и те агенты пользователей, которые имеют возможность "предположить" charset ДОЛЖНЫ при первоначальном отображении документа использовать charset из поля content-type, если они поддерживают такой charset, а затем использовать собственные установки.

2007 - 2017 © Русские переводы RFC, IETF, ISOC.