Pregunta Encabezados HTTP personalizados: convenciones de nombres


Varios de nuestros usuarios nos han pedido que incluyamos datos relativos a su cuenta en el Encabezados HTTP de las solicitudes que les enviamos, o incluso las respuestas que obtienen de nuestra API. ¿Cuál es la convención general para agregar encabezados HTTP personalizados, en términos de nombrando, formato... etc.

Además, siéntase libre de publicar cualquier uso inteligente de estos con los que tropezó en la web; Estamos tratando de implementar esto usando lo mejor que hay como objetivo :)


866
2017-08-24 21:59


origen


Respuestas:


En junio de 2012, la desaprobación de la recomendación de usar el prefijo "X-" se ha vuelto oficial RFC 6648. A continuación hay citas de relevancia:

3. Recomendaciones para creadores de nuevos parámetros

...

  1. NO DEBE prefijar los nombres de sus parámetros con "X-" o similar      construcciones

4. Recomendaciones para diseñadores de protocolo

...

  1. NO DEBE prohibir los parámetros con un prefijo "X" o similar      construcciones de ser registrado.

  2. NO DEBE estipular que un parámetro con un prefijo "X-" o      construcciones similares deben entenderse como no estandarizadas.

  3. NO DEBE estipular que un parámetro sin un prefijo "X-" o      construcciones similares deben entenderse como estandarizadas.

Tenga en cuenta que "NO DEBE" ("desalentado") no es lo mismo que "NO DEBE" ("prohibido"), consulte también RFC 2119 para otra especificación en esas palabras clave. En otras palabras, puede seguir usando los encabezados prefijados "X", pero no es recomendable y no puede documentarlos como si fueran estándares públicos.


En junio de 2011, el primero Borrador del IETF fue publicado en desaprobar la recomendación de usar el prefijo "X-" para encabezados no estándar. La razón es que cuando los encabezados no estándar con el prefijo "X-" se convierten en estándar, al eliminar el prefijo "X-" se rompe la compatibilidad hacia atrás, lo que obliga a los protocolos de aplicaciones a admitir ambos nombres (E.g, x-gzip & gzip ahora son equivalentes). Entonces, la recomendación es solo nombrarlos sesudamente sin el prefijo "X-".


La recomendación es  estaba para comenzar su nombre con "X-". P.ej. X-Forwarded-For, X-Requested-With. Esto también se menciona en a.o. sección 5 de RFC 2047.


956
2017-08-24 22:02



La pregunta es volver a leer. La pregunta real formulada no es similar a los prefijos de los proveedores en las propiedades de CSS, donde es apropiado tener en cuenta el futuro y pensar en el soporte del proveedor y las normas oficiales. La pregunta real es más similar a elegir los nombres de los parámetros de consulta de URL. Nadie debería importar lo que son. Pero el espaciado de nombres de los personalizados es una acción perfectamente válida, común y correcta.

Razón fundamental:
Se trata convenciones entre desarrolladores para encabezados personalizados, específicos de la aplicación - "datos relevantes para su cuenta"- que no tienen nada que ver con proveedores, organismos de estándares o protocolos para ser implementados por terceros, excepto que el desarrollador en cuestión simplemente necesita evitar nombres de encabezados que puedan tener otro uso previsto por servidores, proxies o clientes. Por lo tanto, los ejemplos "X-Gzip / Gzip" y "X-Forwarded-For / Forwarded-For" son discutibles. La pregunta que se plantea es sobre convenciones en el contexto de una API privada, similar a las convenciones de nomenclatura de parámetros de consulta URL. una cuestión de preferencia y espaciado entre 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 sobre el prefijo "X-", pero ayuda a dejar en claro que es un encabezado personalizado. De hecho, RFC-6648 y otros ayudan a reforzar el uso de un prefijo "X-", ya que, a medida que los proveedores de clientes y servidores HTTP abandonan el prefijo, su API específica de la aplicación, datos personales el mecanismo de paso está cada vez mejor aislado de las colisiones de nombres y espacios con el pequeño número de nombres de encabezado reservados oficiales. Dicho esto, mi preferencia y recomendación personal es ir un paso más allá y hacerlo, por ejemplo. "X-ACME-ClientDataFoo" (si su empresa de widgets es "ACME").

En mi humilde opinión, la especificación del IETF no es lo suficientemente específica para responder la pregunta del OP, porque no distingue entre casos de uso completamente diferentes: (A) vendedores que introducen nuevas características globales aplicables como "Reenviar-Por", por un lado, vs. (B) desarrolladores de aplicaciones que transmiten cadenas específicas de la aplicación a / desde el cliente y el servidor. La especificación solo se refiere a la primera, (A). La pregunta aquí es si hay convenciones para (B). Existen. Implican agrupar los parámetros alfabéticamente y separarlos de los muchos encabezados relevantes para estándares del 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 proveedores dejen de usar "X-" para (A), más limpios y distintivos serán los (B).

Ejemplo: 
Google (que tiene un poco de peso en los distintos organismos de estándares) es -al día de hoy, 20141102 en esta ligera edición de mi respuesta- que actualmente usa "X-Mod-Pagespeed" para indicar la versión de su módulo Apache involucrado en transformando una respuesta dada. ¿Alguien realmente está sugiriendo que Google debería usar "Mod-Pagespeed", sin la "X-", y / o pedirle al IETF que bendiga su uso?

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


413
2017-10-28 16:39



El formato para los encabezados HTTP se define en la especificación HTTP. Voy a hablar sobre 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. Ambos se definen en la sección 2.2, "Reglas 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

TEXTO es:

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

Donde LWS es un espacio en blanco lineal, cuya definición no reproduciré, y OCTET 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 encabezado nombre debe estar compuesto de un subconjunto de caracteres ASCII: caracteres alfanuméricos, cierta puntuación, no mucho más. En segundo lugar, no hay nada en la definición de un encabezado valoreso lo restringe a ASCII o excluye caracteres de 8 bits: está compuesto explícitamente por octetos, con solo los caracteres de control restringidos (tenga en cuenta que CR y LF se consideran controles). Además, el comentario sobre la producción de TEXT implica que los octetos deben interpretarse como 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.

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

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


56
2017-08-25 19:49



El registro del nombre del campo del encabezado se define en RFC3864, y no hay nada especial con "X-".

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

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


15
2017-08-25 06:44



Modificando, o más correctamente, agregando los encabezados HTTP adicionales son una gran herramienta de depuración de código si nada más.

Cuando una solicitud de URL devuelve un redireccionamiento o una imagen, no hay una "página" html para escribir temporalmente los resultados del código de depuración, al menos no uno que esté 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 se depuran.

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 hubieran sido muy difíciles de rastrear.


14
2017-07-04 09:29



RFC6648 le recomienda asumir que su encabezado personalizado "puede estandarizarse, publicarse, desplegarse comúnmente o utilizarse en múltiples implementaciones". Por lo tanto, recomienda no agregarle un prefijo "X" o construcciones similares.

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


1
2017-07-24 13:50