HTML многочастная форма - максимальная длина "граничной" строки? - PullRequest
Новая
       5

HTML многочастная форма - максимальная длина "граничной" строки?

6 голосов
/ 24 ноября 2011

В форме, состоящей из нескольких частей (т. Е. Content-Type=multipart/form-data), существует ли верхний предел длины строки границы, которую должен принимать сервер HTTP?

Насколько я могу судить, соответствующийВ RFC написано 70 символов:

  • В RFC2616 (HTTP / 1.1) в разделе «3.7 Типы мультимедиа» сказано, что разрешенные типы в заголовке Content-Type определяются как RFC1590. (Процедура регистрации типа носителя).
  • RFC1590 Обновление RFC-1521 (MIME).
  • RFC1521 говорит, что граница "должна быть не длиннее 70 символов, не считая двух ведущих дефисов".
  • Этот же текст также появляется в RFC2046 который предположительно устарел RFC1521 .

Так могу ли я быть уверен, что все основные браузеры HTTP / 1.1, существующие сегодня, придерживаются этого ограничения?Известны ли какие-либо браузеры (или другие HTTP-клиенты / библиотеки), которые нарушают этот предел?

Есть ли какая-то другая спецификация или общее правило, которое я пропускаю и которое говорит, что строка будет на короче чем 70 символов?В Chrome (ium) я получаю что-то вроде этого: ----WebKitFormBoundaryLu4dNSGEhJZUgoe5, который, очевидно, короче, чем 70 символов.

Я задаю этот вопрос, потому что мой сервер работает в среде с крайне ограниченными памятью, поэтому "malloc буфер, достаточно большой, чтобы вместить всю строку заголовка "не идеальный ответ.

1 Ответ

6 голосов
/ 08 октября 2013

Как вы заметили, RFC 2046 обновил спецификацию MIME, но сохранил ограничение максимальной строки границы до 70 символов, не считая двух ведущих дефисов.

Я думаю, что это справедливое предположение, что за спецификацией следуют все основные браузеры (и все клиенты, использующие MIME, например почтовые программы), поскольку в противном случае передача многочастных данных была бы действительно очень рискованной.

Конечно, я экспериментально проверил это для вас, используя последние версии:

  • curl: ----------------------------5a56a6c893f2 (40)
  • Chrome 30 (WebKit): ----WebKitFormBoundarym0vCJKBpUYdCIWQG (38)
  • Safari 6 (WebKit и Chrome): ----WebKitFormBoundaryFHUXvJBZwO2JKkNa (38)
  • FireFox 24: ---------------------------7096603861379320641089344535 (55)
  • IE 10: ---------------------------7dd1961640278 (40) - та же техника, что и у curl!
  • Apache HttpClient: -----------------------------1294919323195 (42)

Таким образом, не только каждый основной браузер / клиент соответствует, но и все позволит вам сэкономить 15 выделенных байтов на границу на буфер из теоретического максимума. Если бы вы могли тривиально включить пользовательский агент, вы могли бы снизить производительность. ; -)

...