¿Pueden indicarse los valores del encabezado?
Si quiere decir que la producción de RFC 5987 parameter se aplica a la parte principal del valor del encabezado, entonces no.
Some-Header: "foo"; bar*=utf-8'en'bof
Aquí la parte principal del valor de la cabecera probablemente sería "foo" incluyendo las comillas, pero ...
¿Cuál es la importancia de un punto y coma (;)?
El manejo específico se define para cada encabezado con nombre por separado. Por lo tanto, el punto y coma es significativo para, por ejemplo, Content-Disposition, pero no para Content-Length.
Obviamente, esta no es una solución muy satisfactoria, pero eso es a lo que nos tenemos que atascar.
estoy haciendo un proxy transparente que necesita para manejar y modificar muchos campos de cabecera en estado salvaje transparente.
No puede manejar esto de forma genérica, debe conocer la forma de cada encabezado posible. Para cualquier cosa que no reconozca, no intente descomponer el valor del encabezado; y realmente, muy poco por ahí es compatible con RFC 5987 por el momento, es poco probable que pueda hacer un manejo muy útil de él.
El estado actual es que los caracteres que no son ASCII en los valores de encabezado no funcionan lo suficientemente bien entre navegadores para usarse, codificados o sin formato.
Por suerte, rara vez se necesitan. El único caso de uso realmente común es el de los nombres de archivo no ASCII para Content-Disposition, pero es más fácil solucionarlo colocando en su lugar el nombre de archivo en una parte de la ruta URL final.
¿Podría el analizador de valores para un encabezado HTTP considerarse un analizador MIME?
No. HTTP toma mucho de MIME y la familia de estándares RFC 822 en general, pero no es parte de la familia 822.Tiene su propia gramática de bajo nivel para encabezados que se parece a 822, pero no es del todo compatible. Las características MIME arbitrarias no se pueden usar en HTTP, tiene que haber un mecanismo de estandarización para arrastrarlas a HTTP explícitamente, que es lo que RFC 5987 es, para (partes de) RFC 2231.
(Ver sección 19.4 de RFC 2616 para la discusión de algunas otras diferencias.)
En teoría, una presentación multipart forma es parte de la familia 822 y usted debería ser capaz de utilizar el RFC 2231 codificación allí. Pero la realidad es que los navegadores tampoco lo admiten.