MIME RFC "Content-Type" параметр путаница? Непонятная спецификация RFC

Я пытаюсь реализовать базовый парсер MIME для multipart/related в C++/Qt.

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

Из RFC882 Раздел 3.1.1:

Каждое поле заголовка можно рассматривать как одну логическую строку символов ASCII, содержащую имя поля и тело поля. Для удобства часть тела этого концептуального объекта может быть разбита на многострочное представление; это называется "складывание". Общее правило состоит в том, что там, где может быть линейно-пробел (НЕ просто LWSP-символы), вместо этого может быть вставлен CRLF, за которым сразу следует ПО СЛЕДУЮЩЕМУ одному LWSP-символу. Таким образом, единственная линия

Хорошо, так что я просто анализирую поле заголовка, и если CRLF следует с линейным пробелом, я просто объединяю их полезным способом, чтобы получить одну строку заголовка. Давайте продолжим...

Из RFC2045 Раздел 5.1:

В расширенной нотации BNF в RFC 822 значение поля заголовка Content-Type определяется следующим образом:

 content := "Content-Type" ":" type "/" subtype
            *(";" parameter)
            ; Matching of media type and subtype
            ; is ALWAYS case-insensitive.

[...]

 parameter := attribute "=" value

 attribute := token
              ; Matching of attributes
              ; is ALWAYS case-insensitive.

 value := token / quoted-string

 token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
             or tspecials>

Хорошо. Так что, если вы хотите указать Content-Type Заголовок с параметрами, просто сделайте это так:

Content-Type: multipart/related; foo=bar; something=else

... и свернутая версия того же заголовка будет выглядеть так:

Content-Type: multipart/related;
    foo=bar;
    something=else

Правильный? Хорошо. Поскольку я продолжал читать RFC, я столкнулся со следующим в Разделе 5.1 RFC2387 (Примеры):

 Content-Type: Multipart/Related; boundary=example-1
         start="<950120.aaCC@XIson.com>";
         type="Application/X-FixedRecord"
         start-info="-o ps"

 --example-1
 Content-Type: Application/X-FixedRecord
 Content-ID: <950120.aaCC@XIson.com>

 [data]
 --example-1
 Content-Type: Application/octet-stream
 Content-Description: The fixed length records
 Content-Transfer-Encoding: base64
 Content-ID: <950120.aaCB@XIson.com>

 [data]

 --example-1--

Хм, это странно. Вы видите Content-Type заголовок? У него есть ряд параметров, но не у всех есть ";" в качестве разделителя параметров.

Может быть, я просто не правильно прочитал RFC, но если мой парсер работает строго так, как определяет спецификация, type а также start-info параметры могут привести к одной строке или, что еще хуже, к ошибке синтаксического анализатора.

Ребята, что вы думаете по этому поводу? Просто опечатка в RFC? Или я что-то пропустил?

Спасибо!

Источник

2 ответа

Решение

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

Источник

Вполне возможно, опечатка, но в целом (и из опыта) вы должны быть в состоянии справиться с такого рода вещи "в дикой природе", а также. В частности, почтовые клиенты сильно различаются по своей способности генерировать действительные сообщения и следовать всем соответствующим спецификациям (во всяком случае, в мире электронной почты /SMTP это даже хуже, чем в мире WWW!)

Источник
Другие вопросы по тегам