У меня возник вопрос относительно дизайна этих протоколов. Почему мы используем границу для разделения частей многочастного сообщения вместо того, чтобы вводить длину контента для каждой части? Используя длину, синтаксический анализ будет проще. Упускаю ли я основную причину использования границ, а не параметра длины? Благодаря!Http/Smtp MIME multipart. Почему граница?
Использование длины синтаксический будет [быть] проще
Здесь вы ошибаетесь. У авторов многопрофильного MIME были случаи, когда вы не могли заранее определить длину части сообщения. Подумайте о кодировках контента, которые изменяют длины сообщений, такие как base64, UUencode и другие. Там также есть сжатие, шифрование и многое другое. Также: Content-Length является заголовком объекта. Это означает, что если вы достигнете этого, вы уже начали разбирать часть сообщения. Он не имеет никакого преимущества над граничным маркером.
Если вы изучаете старые протоколы, вы часто сталкиваетесь с каким-либо маркером (обычно \0), чтобы указать конец сообщения. Отправка количества байтов сообщения является еще одним решением, но вы не найдете его много в тех местах, где контент сообщения должен быть преобразован «на лету» или каким-то образом будет передаваться потоком.
Итог: многогранная граница позволяет некоторым интересным приложениям с содержимым сообщения непредсказуемого размера. HTTP server pushing - примечательный пример.
Потому что в старые добрые времена стандарт MIME был определен таким образом. Возможно, одна из причин заключалась в том, что длина содержимого имеет проблемы с текстовыми/открытыми данными, где новая строка может быть либо CR (старый mac), либо LF (unix), либо CR LF (windows, dos). Другой может быть, что человеку легче читать, что является ИМХО плохим аргументом, но часто случается, когда предпочитаете текстовые представления, такие как HTTP, XML или SOAP, вместо более эффективных двоичных способов, таких как ASN.1 или SUN RPC.
Вы можете также просмотреть его как успешную попытку отрасли, чтобы продать более мощные серверы, вводя бесполезные накладные расходы в протоколы :)
Большое спасибо Стефану! Просто следующий вопрос. Вы указываете возможный priblem с символом конца строки. Но почему? Контент-длина будет просто считать фактические символы (cr o cr + lf). Почему это может привести к проблеме при разборе? – Michael
, поскольку MTA (почтовые агенты передачи) и MUA (почтовые пользовательские агенты, например почтовый клиент) могут изменять сообщение, если содержимое не изменяется. Например, если MTA не понимает двоичный код Content-Transfer-Encoding, отправляющая MUA/MTA преобразует его в base64. Кроме того, текстовые/простые данные, прикрепленные к платформе Windows (строка, заканчивающаяся CR LF), автоматически преобразуются в конец строки LF, если они прочитаны/сохранены на платформе unix. Хотя это может показаться хорошей идеей в теории на самом деле, это создает массу проблем, потому что многие MUA устанавливают контент-тип текста/plain даже для двоичного контента :( –
Но, как я понимаю, длина контента - это номер байтов и не зависит от кодировки.Таким образом, если MTA/MUA изменяет сообщение, оно также обновит поле длины содержимого. Нет? – Michael
Но это зависит от того, как вы определяете длину содержимого. Вы всегда можете использовать это количество байтов, фактически отправленных в текущей части (после кодирования и/или сжатия). В этом случае вы всегда знаете, когда часть закончена, просто подсчитывая вместо сопоставления с образцом. Я что-то упускаю? – Michael
Да. Вы не можете это сделать, если, например, вы генерируете контент сообщения динамически или если вы ограничены по ресурсам таким образом, который не позволяет обрабатывать часть сообщения в целом. Чтобы оставаться в современных стандартах, представьте себе сообщения размером в несколько гигабайт. Btw: заголовок 'Content-Length' определен точно так же, как вы писали здесь. – DaSourcerer
Да, с префиксом каждого фрагмента данных с длиной и последующей маркировкой последнего фрагмента данных особым образом вы можете передавать данные без предварительной регистрации, зная общий размер. Гораздо проще разобрать, чем многопользовательский MIME. Это делается в кодировке передачи с чередованием HTTP. –