Можно ли указывать значения заголовка в кавычках?
Если вы имеете в виду, применяется ли производство RFC 5987 parameter к основной части значения заголовка, то нет.
Some-Header: "foo"; bar*=utf-8'en'bof
Здесь основная часть значения заголовка, вероятно, будет "foo", включая кавычки, но ...
Что означает точка с запятой (;)?
Специальная обработка определяется для каждого именованного заголовка отдельно. Таким образом, точка с запятой имеет значение, скажем, для Content-Disposition, но не для Content-Length.
Очевидно, что это не очень удовлетворительное решение, но это то, с чем мы застряли.
Я делаю прозрачный прокси, который должен прозрачно обрабатывать и изменять многие поля заголовка in-the-wild.
Вы не можете обрабатывать их в общем виде, вы должны знать форму каждого возможного заголовка. Для всего, что вы не узнаете, не пытайтесь разложить значение заголовка; и действительно, на данный момент так мало кто поддерживает RFC 5987, вряд ли вы сможете сделать много полезного для его обработки.
На сегодняшний день статус-кво состоит в том, что не-ASCII-символы в значениях заголовка не работают достаточно кросс-браузерно, чтобы их можно было использовать как в кодированном, так и в необработанном виде.
К счастью, они редко нужны. Единственный действительно распространенный вариант использования - это имена файлов, отличные от ASCII, для Content-Disposition, но это легче обойти, поместив имя файла в конечную часть пути URL.
Может ли анализатор значений для заголовка HTTP считаться анализатором MIME?
Нет. HTTP в значительной степени заимствует из MIME и семейства стандартов RFC 822 в целом, но он не входит в семейство 822. Он имеет собственную низкоуровневую грамматику для заголовков, которая выглядит как 822, но не совсем совместима. Произвольные функции MIME нельзя использовать в HTTP, должен существовать механизм стандартизации для явного перетаскивания их в HTTP - то, чем является RFC 5987 для (частей) RFC 2231.
(См. Раздел 19.4 RFC 2616 для обсуждения некоторых других отличий.)
Теоретически, multipart отправка формы является частью семейства 822, и вы должны иметь возможность использовать там кодировку RFC 2231. Но реальность такова, что браузеры тоже не поддерживают это.