Максимальная длина поля заголовка MIME Content-Type? - PullRequest
Новая
       51

Максимальная длина поля заголовка MIME Content-Type?

33 голосов
/ 21 августа 2008

Я просто проектирую схему для таблицы базы данных, которая будет содержать подробности вложений электронной почты - их размер в байтах, имя файла и тип содержимого (то есть "image / jpg", "audio / mp3" и т. Д.).

Кто-нибудь знает максимальную длину, которую я могу ожидать от типа контента?

Ответы [ 3 ]

43 голосов
/ 05 декабря 2009

Я надеюсь, что не ошибся, но похоже, что длина составляет максимум 127/127 или 255 всего .

RFC 4288 имеет ссылку в 4.2 (стр. 6): 

Type and subtype names MUST conform to the following ABNF:

   type-name = reg-name
   subtype-name = reg-name

   reg-name = 1*127reg-name-chars
   reg-name-chars = ALPHA / DIGIT / "!" /
                   "#" / "$" / "&" / "." /
                   "+" / "-" / "^" / "_"

Мне не ясно, может ли суффикс + добавить после 127, но это не так.

6 голосов
/ 29 мая 2014

В RFC 6838, который является последним стандартом и устарел RFC4288, есть следующее утверждение.

"Также обратите внимание, что хотя этот синтаксис допускает имена длиной до 127 символов, ограничения реализации могут сделать такие длинные имена проблематичными. По этой причине <type-name> и <subtype-name> ДОЛЖНЫ быть ограничены 64 символами."

64 + 1 + 64 = 129.

Но я подозреваю, что стандарт должен означать 63 + 1 + 63 = 127.

ссылка: https://tools.ietf.org/html/rfc6838#section-4.2

1 голос
/ 26 сентября 2008

Мы используем систему SaaS, которая позволяет пользователям загружать файлы. Мы изначально разработали его для хранения типов MIME до 50 символов. За последние несколько дней мы видели несколько попыток загрузить 71-байтовые типы. Итак, мы переходим на 250. 100 показалось «хорошим», но это всего лишь несколько больше, чем максимум, который мы видим сейчас. 500 кажется глупым, поэтому 250 является выбранным.

...