Кратко

  • RFC 1806 добавил к MIME значения inline, attachment и необязательное имя файла как пожелания отправителя, а не подтверждения показа или сохранения.
  • RFC 2183 расширил набор датами и примерным размером, но прямо сохранял проверку имени за получателем и предупреждал, что Unix st_ctime не является временем создания.
  • Международная кодировка и перенос механизма в HTTP и формы улучшили передачу метаданных, не дав удалённой стороне права выбирать локальный путь, перезаписывать или запускать.

MIME описывал содержимое, но не следующий поступок

RFC 1521 позволил интернет-почте переносить текст, изображения, прикладные данные и вложенные multipart-структуры. Позднее RFC 2045 и RFC 2046 закрепили правила кодирования и типов. Получатель мог отделить часть, декодировать байты и узнать заявленный тип носителя.

Из этого ещё не следовал способ показа. Графический клиент мог встроить изображение в письмо, терминал — перечислить доступные части, а политика безопасности — запретить автоматическую обработку известного типа. Отправитель знал роль материала в сообщении; получатель знал возможности и риски своей среды.

Экспериментальный RFC 1806, опубликованный в июне 1995 года, предложил необязательное поле Content-Disposition для любой MIME-сущности. Без него пользовательский агент оставался свободен выбрать подходящее представление. Поле добавляло удалённое намерение к решению получателя, но не заменяло его.

Два значения задавали только ближайший порог

inline означал желательное автоматическое представление в обычном потоке с учётом правил окружающего multipart-контейнера. attachment требовал перед показом дополнительного действия пользователя. Стандарт не предписывал конкретную кнопку, значок или список.

Оба значения смотрели вперёд. inline не доказывал наличие декодера, прохождение проверки или фактический показ человеку. attachment не доказывал нажатие, сохранение либо открытие. Заголовок фиксировал просьбу о следующем шаге; результат должен был появиться в другом свидетельстве.

Во вложенных контейнерах пороги шли последовательно. Disposition на multipart-сущности относился ко всему контейнеру. Если внешний контейнер был вложением, внутренние disposition становились значимы лишь после его открытия. По внешней метке нельзя было заключить, что читатель добрался до глубокой части.

Неизвестное значение RFC 1806 предписывал трактовать как attachment, а неизвестные параметры разрешал игнорировать. Новое слово не получало автоматического доступа к экрану только потому, что клиент ещё не понимал его. Неопределённость увеличивала число необходимых действий, а не эффект.

Имя было предложением при условии сохранения

Необязательный filename предлагал имя на тот случай, если получатель решит отделить часть и сохранить её. Параметр мог сопровождать и inline, не создавая файла. Наличие строки не было квитанцией файловой системы.

RFC 1806 требовал не уважать сведения о каталогах в присланном значении, приспосабливать конечный компонент к местным правилам и не перезаписывать существующие файлы. Только получатель знает свои разделители, зарезервированные имена, разрешённые каталоги, занятые имена и связь расширений с программами.

Раздел безопасности перечислял конкретные потери: создание стартового файла, замена системного или пользовательского файла, помещение исполняемого содержимого в путь поиска команд, отправка данных в канал. Имя и размещение не должны были приводить к интерпретации или исполнению без явной инициативы пользователя.

Между сообщением и эффектом лежит цепочка: сырая строка, результат разбора, удаление смысла пути, решение о коллизии, фактическое локальное имя, запись байтов, возможное открытие приложением. Каждое звено отвечает на собственный вопрос. Первый заголовок не может подтвердить последние события.

Файловая карточка всё ещё рассказывала со слов отправителя

Информационная запись RFC 1806 показывает, что в августе 1997 года её сменил Proposed Standard RFC 2183. Новая версия сохранила inline, attachment и обязанность получателя проверять имя. Она добавила даты создания, изменения и чтения, а также примерный размер.

Эти данные были полезны, но не аутентифицировали прошлое объекта. RFC 2183 отдельно предупреждал разработчиков Unix и POSIX: st_ctime обозначает не время создания. Получатель мог решить сохранить присланную дату, но не получал тем самым надёжную хронологию. Примерный размер помогал оценить место; он не был хешем, гарантией выделения пространства или подтверждением завершённой записи.

RFC 2183 также ввёл процедуру регистрации расширений. Современный реестр IANA Content Disposition содержит исходные и последующие значения для разных протокольных контекстов. Регистрация доказывает наличие публичного определения. Она не доказывает реализацию в конкретном клиенте и не делает значение универсальным для каждой позиции.

Человеческие имена потребовали новой формы

RFC 1806 признавал ограничение filename набором US-ASCII. RFC 2231 добавил нумерованные продолжения длинных параметров и расширенную запись с кодировкой, необязательным языком и процентно закодированными октетами.

Восстановление имени стало отдельным процессом. Сегменты могут отсутствовать или меняться местами, кодированные и обычные формы — смешиваться, набор символов — быть неизвестным, а байты — ошибочными. Итоговая строка Unicode является результатом выбора и декодирования, поэтому исходные компоненты нельзя терять.

Правильно отображённое имя не становится безопасным. Точно декодированный выход из каталога остаётся выходом, а зарезервированное имя устройства — зарезервированным. RFC 2231 решила задачу представления языка, не задачу локального разрешения.

HTTP сначала внедрил поле, затем стандартизовал

В 1999 году RFC 2616 отмечал, что Content-Disposition часто реализуется в HTTP, хотя ещё не является частью стандарта HTTP. Веб-серверы уже хотели предложить отдельное скачивание и удобное имя.

RFC 6266 стандартизировал поле ответа в 2011 году. Имя там лишь совет. Пользовательский агент должен не позволять серверу выбирать неразрешённое место, отбросить все компоненты пути кроме последнего, проверять опасные расширения, убирать управляющие символы и обезвреживать имена со специальным смыслом для файловой системы или оболочки.

Ответ может содержать совместимый filename и расширенный filename*; понимающий оба клиент должен предпочесть второй. RFC 8187 уточнил расширенные HTTP-параметры и обязал поддерживать UTF-8. Если варианты расходятся, выбор параметра, декодер и показанное имя должны оставаться различимыми фактами.

Форма поменяла отправителя и получателя местами

Content-Disposition встречается и внутри multipart/form-data, но RFC 6266 явно исключает такие поля частей тела из своего профиля ответа. RFC 7578 требует для каждой части form-data и параметр name, а для файловой части допускает необязательный filename, если осмысленное имя известно.

Здесь браузер передаёт имя, а веб-приложение защищает собственное хранилище. Оно обязано отбросить каталог, применить местные правила и само выбрать место. Более того, RFC 7578 запрещает filename* в этом контексте, хотя ответ на скачивание его использует. Одинаковое имя поля не отменяет направление и положение в протоколе.

История поэтому не сводится к переходу от почтовой скрепки к веб-загрузке. Через разные среды прошёл ограниченный договор: удалённая сторона сообщает предпочтение и метаданные, локальная сторона принимает решение и несёт последствия.

Источники