Encabezados HTTP personalizados: convenciones de nomenclatura

La pregunta merece una relectura. La pregunta real que se hace no es similar a los prefijos de proveedor en las propiedades CSS, donde la preparación para el futuro y el pensamiento sobre el soporte del proveedor y los estándares oficiales son apropiados. La pregunta real es más similar a elegir nombres de parámetros de consulta de URL. A nadie debería importarle lo que son. Pero el espaciado de nombres de los personalizados es una cosa perfectamente válida, común y correcta.

Justificación:
Se trata de convenciones entre desarrolladores para encabezados personalizados y específicos de la aplicación -- "datos relevantes para su cuenta " which que no tienen nada que ver con proveedores, organismos de estándares o protocolos a ser implementados por terceros, excepto que el desarrollador en cuestión simplemente necesita evitar nombres de encabezado que puedan tener otro uso previsto por servidores, proxies o clientes. Por esta razón, el "X-Gzip/Gzip" y "X-Forwarded-For/Forwarded-For" los ejemplos son inútiles. La pregunta planteada es acerca de las convenciones en el contexto de una API privada, similar a las convenciones de nomenclatura de parámetros de consulta de URL. Es una cuestión de preferencias y espaciado de nombres; las preocupaciones acerca de que "X-ClientDataFoo "sea compatible con cualquier proxy o proveedor sin la" X " están claramente fuera de lugar.

No hay nada especial o mágico en el prefijo "X -", pero ayuda a dejar claro que es un encabezado personalizado. De hecho, RFC-6648 et al ayudan a reforzar el caso para el uso de un prefijo " X -", porque as como los proveedores de clientes HTTP y servidores abandonan el prefijo: su mecanismo de paso de datos personales, API privada y específico de la aplicación se está aislando aún mejor contra las colisiones de espacio de nombres con el pequeño número de nombres de encabezado reservados oficiales. Dicho esto, mi preferencia personal y recomendación es ir un paso más allá y hacer, por ejemplo, "X-ACME-ClientDataFoo "(si su compañía de widgets es"ACME").

En mi humilde opinión, la especificación IETF no es lo suficientemente específica para responder a la pregunta del OP, porque no distingue entre usos completamente diferentes casos: (A) proveedores que introducen nuevas funciones aplicables a nivel mundial, como "Forwarded-For", por un lado, frente a (B) desarrolladores de aplicaciones que pasan cadenas específicas de la aplicación hacia/desde el cliente y el servidor. La especificación solo se refiere a la primera, (A). La cuestión aquí es si hay convenciones para (B). Las hay. Implican agrupar los parámetros en orden alfabético, y separarlos de los muchos encabezados relevantes para estándares de tipo (A). Usar el prefijo" X - "o" X-ACME - " es conveniente y legítimo para (B), y no entra en conflicto con (A). Cuantos más vendedores dejen de usar "X-" para (A), más claramente distintos serán los (B).

Ejemplo:
Google (que tienen un poco de peso en los diversos cuerpos de estándares) están using a partir de hoy, 20141102 en esta ligera edición de mi respuesta using actualmente utilizando "X-Mod-Pagespeed" para indicar la versión de su módulo Apache involucrado en la transformación de una respuesta dada. ¿Alguien realmente sugiere que Google debería usar "Mod-Pagespeed", sin la" X -", y/o pedir a la IETF que bendiga su uso?

Resumen:
Si está utilizando encabezados HTTP personalizados (como una alternativa a veces apropiada a las cookies) dentro de su aplicación para pasar datos a/desde su servidor, y estos encabezados, explícitamente, NO están destinados a usarse fuera del contexto de su aplicación, el espaciado de nombres con un prefijo "X-" o "X-FOO-" es una convención razonable y común.

El formato de los encabezados HTTP se define en la especificación HTTP. Voy a hablar de HTTP 1.1, para el cual la especificación es RFC 2616. En la sección 4.2, 'Encabezados de mensaje', se define la estructura general de un encabezado:

   message-header = field-name ":" [ field-value ]
   field-name     = token
   field-value    = *( field-content | LWS )
   field-content  = <the OCTETs making up the field-value
                    and consisting of either *TEXT or combinations
                    of token, separators, and quoted-string>

Esta definición se basa en dos pilares principales, token y TEXTO. Ambas se definen en la sección 2.2, "Normas básicas". Token es:

   token          = 1*<any CHAR except CTLs or separators>

A su vez descansando en CHAR, CTL y separadores:

   CHAR           = <any US-ASCII character (octets 0 - 127)>

   CTL            = <any US-ASCII control character
                    (octets 0 - 31) and DEL (127)>

   separators     = "(" | ")" | "<" | ">" | "@"
                  | "," | ";" | ":" | "\" | <">
                  | "/" | "[" | "]" | "?" | "="
                  | "{" | "}" | SP | HT

EL TEXTO es:

   TEXT           = <any OCTET except CTLs,
                    but including LWS>

Donde está LWS espacio en blanco lineal, cuya definición no reproduciré, y OCTETO es:

   OCTET          = <any 8-bit sequence of data>

Hay una nota que acompaña a la definición:

The TEXT rule is only used for descriptive field contents and values
that are not intended to be interpreted by the message parser. Words
of *TEXT MAY contain characters from character sets other than ISO-
8859-1 [22] only when encoded according to the rules of RFC 2047
[14].

Entonces, dos conclusiones. En primer lugar, está claro que el nombre del encabezado debe estar compuesto por un subconjunto de caracteres ASCII - alfanuméricos, alguna puntuación, no mucho más. En segundo lugar, no hay nada en la definición de un valor de encabezado que lo restrinja a ASCII o excluya los caracteres de 8 bits: está compuesto explícitamente de octetos, con solo caracteres de control barrados (tenga en cuenta que CR y LF se consideran controles). Además, el comentario sobre la producción de TEXTO implica que los octetos deben interpretarse como si estuvieran en ISO-8859-1, y que hay un mecanismo de codificación (que es horrible, por cierto) para representar caracteres fuera de esa codificación.

Por lo tanto, para responder a @BalusC en particular, es bastante claro que de acuerdo con la especificación, los valores de encabezado están en ISO-8859-1. He enviado high-8859-1 caracteres (específicamente, algunas vocales acentuadas como se usa en francés) en un encabezado de Tomcat, y las hizo interpretar correctamente por Firefox, por lo que hasta cierto punto, esto funciona en la práctica, así como en teoría (aunque se trataba de un encabezado de ubicación, que contiene una URL, y estos caracteres no son legales en las URL, por lo que esto era en realidad ilegal, pero bajo una regla diferente!).

Dicho esto, no confiaría en ISO-8859-1 trabajando en todos los servidores, proxies y clientes, por lo que me adheriría a ASCII como una cuestión de programación defensiva.

El registro de nombres de campos de encabezado está definido en RFC3864, y no hay nada especial con "X-".

Por lo que puedo decir, no hay pautas para los encabezados privados; en duda, evítelos. O eche un vistazo al marco de extensión HTTP (RFC 2774).

Sería interesante entender más del caso de uso; ¿por qué no se puede agregar la información al cuerpo del mensaje?

Modificar, o más correctamente, agregar encabezados HTTP adicionales es una gran herramienta de depuración de código si nada más.

Cuando una solicitud de URL devuelve una redirección o una imagen, no hay una "página" html para escribir temporalmente los resultados del código de depuración, al menos no una que sea visible en un navegador.

Un enfoque es escribir los datos en un archivo de registro local y ver ese archivo más tarde. Otra es agregar temporalmente encabezados HTTP que reflejen los datos y las variables que son depurar.

Regularmente agrego encabezados HTTP adicionales como X-fubar-somevar: o X-testing-someresult: para probar cosas, y he encontrado muchos errores que de otra manera habrían sido muy difíciles de rastrear.

RFC6648 recomienda que asuma que su encabezado personalizado "podría convertirse en estandarizado, público, comúnmente implementado o utilizable en varias implementaciones."Por lo tanto, recomienda no prefijarlo con "X-" o construcciones similares.

Sin embargo, hay una excepción "cuando es extremadamente improbable que [su encabezado] se estandarice alguna vez."Para tales encabezados" específicos de la implementación y de uso privado", el RFC dice que un espacio de nombres como un prefijo de proveedor está justificado.