Кратко

  • В 1998 году обработка одинаковых имён полей оставалась неопределённой; спецификация 2015 года запретила объединять такие части и менять порядок результатов у посредников.
  • Работа Larry Masinter над multipart отделяет сохранность представления от прикладного смысла и разрешения использовать файл. Успешный приём не доказывает все три свойства.

В истории стандартов важны не только новые возможности, но и устранённые неопределённости. Раздел 5.5 спецификации multipart/form-data 1998 года не определял связь порядка полей с порядком возвращаемых значений и обработку одинаковых имён. В редакции 2015 года эти вопросы получили более ясные правила. Небольшое изменение текста обозначило существенную границу: система не должна незаметно превращать несколько полученных частей в одну.

Что именно стало определённым

RFC 7578, опубликованный в июле 2015 года под именем L. Masinter, говорит в разделе 5.2: обработчикам форм с определённым порядком следует возвращать результаты в этом порядке. Посредникам запрещено переставлять результаты, а части с одинаковыми именами полей нельзя объединять. Первая норма имеет силу SHOULD и не требует придумать естественный порядок для любой формы. Два запрета сохраняют различия, которые уже присутствуют во входных данных.

Повторяющееся имя само по себе не означает ошибку. Раздел 4.3 требует отправлять несколько файлов одного поля отдельными частями с одинаковым name. Прежний вложенный вариант multipart/mixed объявлен устаревшим в пользу широко применявшейся практики. Основной текст при этом рекомендует приёмникам широкого назначения поддерживать и старый способ. Это управление переходом, а не безусловная обязанность всякого приложения принимать все исторические варианты.

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

Словарь с одним значением может быть осознанным выбором после проверки количества элементов и применения явного правила. До проверки он убирает свидетельство, что элементов было несколько. Последовательность или структура с несколькими значениями сохраняет возможность разбора. Однако она не разрешает автоматически считать каждую часть допустимой деловой командой. Верность входному представлению и полномочия на действие должны оцениваться отдельно.

До правила было предложение

В ноябре 1995 года E. Nebel и L. Masinter выпустили RFC 1867. Обычные HTML-формы тогда не давали единообразного способа запросить локальные файлы пользователя; сервисам приходилось искать собственные решения. Предложение соединяло выбор файлов, совместимое с MIME представление отправки и путь перехода для старых браузеров. Оно относилось к категории Experimental и прямо не считало себя интернет-стандартом.

RFC 2388, август 1998 года, уже был документом Standards Track и называл L. Masinter автором. Именно в нём оставались упомянутые неопределённости. RFC 7578 заменил его в 2015 году. Имя автора сохранилось, но статус новой спецификации фиксирует публичное рассмотрение и консенсус сообщества IETF. Длительное участие Masinter не даёт оснований приписывать одному человеку все основы MIME и практики браузеров. Его старая личная страница имеет временной контекст 2014 года и не подтверждает нынешнее место работы.

Тело multipart представляет собой ряд частей, разделённых границей. Каждая содержит Content-Disposition типа form-data с параметром name, обозначающим исходное поле. Текст и файлы могут передаваться вместе, оставаясь различимыми. Спецификация 2015 года намеренно не ограничивается HTML или HTTP и охватывает приложения, где человек вообще не заполняет форму на экране. Привычная кнопка загрузки — один из способов воспользоваться форматом, а не его полное определение.

Ещё две границы, которые формат не пересекает

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

Есть и история кодировок. Спецификация советует ASCII для имён полей ради совместимости, либо последовательное использование UTF-8, если другие символы неизбежны. Она описывает соглашения о наборе символов по умолчанию и разнообразие старых генераторов. Параметр filename* в этом формате запрещён: правило из другого контекста заголовков нельзя переносить без проверки.

Наконец, multipart не имеет собственного механизма связи тела с исходной формой. Контекст задаёт приложение, например через адрес обработки или включённые им данные. Формат также не обеспечивает конфиденциальность или целостность. RFC 1867 предупреждал об отправке локальных файлов без явного желания пользователя. RFC 7578 рассматривает непреднамеренное раскрытие, перезапись файлов и исполняемое содержимое. Разбор корректной структуры не подтверждает согласие владельца и не устанавливает безопасность дальнейшего использования.

На чём основаны выводы

Сопоставлены три RFC по ссылкам выше и датированная личная страница. Здесь нет обзора современных библиотек, частоты потерь, тестов производительности или атак. Прикладные последствия — редакционный анализ, а не проверенные дефекты продуктов. Открытый портрет-источник служит опорой для сохранения личности в редакционном изображении, созданном ИИ; рабочая обстановка на фоне вымышлена и не выдаётся за реальный офис.