1001 votos

Los encabezados HTTP personalizadas: convenciones de nomenclatura

Varios de nuestros usuarios nos han pedido que incluya datos relativos a su cuenta en los encabezados HTTP de las peticiones que les enviemos, o incluso las respuestas que obtienen de nuestra API. ¿Qué es la Convención general para agregar los encabezados HTTP personalizadas, en términos de nomenclatura, formato... etc.

Además, no dude en enviar cualquier uso inteligente de estos que tropezó en la web; Estamos tratando de implementar esta usando lo que es mejor por ahí como un objetivo :)

1060voto

BalusC Puntos 498232

El método normal es que fue para iniciar su nombre con "X". Por ejemplo. X-Forwarded-For, X-Requested-With. Esto también se menciona en la sección 5 de RFC 2047.


Actualización: En junio de 2011, el primer borrador IETF fue publicado para desaprobar el uso de la "X" como prefijo para los no-encabezados estándar. La razón es que cuando no estándar, encabezados con el prefijo "X" convertido en estándar, la eliminación de la "X" prefijo de saltos de compatibilidad hacia atrás, obligando a la aplicación de los protocolos para apoyar ambos nombres (por Ejemplo, x-gzip & gzip son ahora equivalentes). Así, la recomendación es sólo el nombre de ellos con sensatez, sin la "X" como prefijo.


Actualización 2: En junio de 2012, la desatención de las "X" prefijo se ha convertido en oficial como RFC 6648.

494voto

cweekly Puntos 814

El aceptó respuesta aquí (por BalusC, Agosto 24, '10) es un casi-sin relación tangente a la pregunta original, que no tiene prácticamente NADA QUE ver CON RFC-6648, RFC-2047, IETF, NI los ORGANISMOS de normalización DE CUALQUIER TIPO. Como una respuesta a la pregunta planteada, es una falta de sentido de la distracción. De hecho, si nada de lo que el citado Rfc conducen precisamente a la CONCLUSIÓN OPUESTA.

La cuestión lleva la re-lectura.

Es acerca de los CONVENIOS ENTRE los DESARROLLADORES PERSONALIZADOS ESPECÍFICOS de la APLICACIÓN, ENCABEZADOS -- "los datos pertinentes a su cuenta", que no tienen NADA QUE ver con los proveedores, organismos de normalización, o los protocolos a ser ejecutados por terceros, salvo que el desarrollador en cuestión simplemente necesita para evitar la cabecera nombres que pudieran tener la intención de uso por parte de los 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 es acerca de los convenios en el contexto de una API privada, similar a la de consulta de URL convenciones de nomenclatura de parámetro. Es una cuestión de preferencia y nombre-espacio; las preocupaciones acerca de "X-ClientDataFoo" estar apoyado por algún proxy o proveedor sin la "X" son claramente fuera de lugar.

No hay nada especial o mágico acerca de la "X" como prefijo, pero ayuda a dejar claro que es un encabezado personalizado. De hecho, RFC-6648 et al hacer una idea MEJOR de lo que ya era utilizar una "X" prefijo, porque a medida que los proveedores de HTTP clientes y servidores de abandonar el prefijo de su aplicación específica, privado de la API, los datos personales-pasar-mecanismo es cada vez mejor aislamiento contra el nombre de espacio de colisiones con el pequeño número de oficiales reservados nombres de encabezado. Dicho esto, mi recomendación es ir un paso más allá y hacer por ejemplo. "X-ACME-ClientDataFoo" (si el widget empresa "ACME").

NB: Es frustrante para tratar de competir con un completamente incorrecta y engañosa, sin embargo, altamente upvoted y aceptado respuesta de una alta reputación usuario. Pero la aceptación de respuesta y su comentario son simplemente responder a una completamente diferente de la pregunta. Sus imaginado pregunta es similar a la de proveedor de los prefijos de las propiedades CSS, donde el futuro y pensar acerca del soporte técnico de los proveedores y de los estándares oficiales es el adecuado. La real pregunta es más similar a la elección de los nombres de los parámetros de consulta de URL. Nadie debería importarle lo que son. Pero en nombre de espaciado de la personalizados es perfectamente válido, y común, y la correcta-cosa que hacer.

Resumen: si estás pasando de la información dentro de la aplicación usando Encabezados HTTP personalizados (que a menudo son preferibles a los de GET o POST parámetros de consulta), nombre-un espacio con una "X" o "X-FOO-" prefijo es una buena idea.

61voto

Tom Anderson Puntos 22456

El formato de los encabezados HTTP se define en la especificación de HTTP. Voy a hablar acerca de HTTP 1.1, por lo que la especificación es el RFC 2616. En la sección 4.2, 'los Encabezados de Mensaje', la estructura general de una cabecera se define:

   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, símbolo y TEXTO. Ambos se definen en la sección 2.2, 'Reglas Básicas'. Token:

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

A su vez descansa sobre 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 LWS es lineal en el espacio en blanco, cuya definición no voy a reproducir, y el OCTETO es:

   OCTET          = <any 8-bit sequence of data>

Hay una nota que acompañ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].

Así pues, dos conclusiones. En primer lugar, es claro que el encabezado nombre debe estar compuesta de un subconjunto de caracteres ASCII - caracteres alfanuméricos, signos de puntuación, no mucho más. En segundo lugar, no hay nada en la definición de un encabezado de valor que se restringe a ASCII o excluye los caracteres de 8 bits: es explícitamente compuesto de octetos, con sólo caracteres de control barradas (tenga en cuenta que CR y LF son considerados los controles). Por otra parte, el comentario sobre el TEXTO de la producción implica que los octetos deben interpretarse como ISO-8859-1, y que hay un mecanismo de codificación (que es horrible, por cierto) para representar los caracteres de fuera de esa codificación.

Así que, para responder a @BalusC en particular, es bastante claro que de acuerdo a la especificación de cabecera, los valores están en ISO-8859-1. He enviado alta-8859-1 caracteres (específicamente, algunos vocales acentuadas como se usa en francés) en un encabezado de Tomcat, y los había interpretado correctamente por Firefox, por lo que, en cierta medida, esto funciona en la práctica como en la teoría (aunque este era un lugar de cabecera, que contiene una dirección URL, y estos personajes no son legales en la Url, así que esto era ilegal, pero bajo una regla diferente!).

Dicho esto, yo no se basan en la norma ISO-8859-1 de trabajo a través de todos los servidores, proxies, y los clientes, así que yo me quedaría a ASCII como una cuestión de defensa de la programación.

16voto

Julian Reschke Puntos 12698

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

En cuanto a que puedo decir, no hay guías para privados encabezados; en caso de duda, evitarlos. O echar un vistazo en el marco de la HTTP extensión (RFC 2774).

Sería interesante saber más del caso de uso; ¿por qué no se puede agregar la información que el cuerpo del mensaje.

16voto

g1smd Puntos 71

Modificación, o, más correctamente, la adición adicional de encabezados HTTP es un gran código de la herramienta de depuración si nada.

Cuando una solicitud de dirección URL devuelve un redirect o en una imagen no hay ninguna html "en la página" temporalmente escribir los resultados de la depuración del código - al menos no uno que sea visible en un navegador.

Un enfoque consiste en escribir los datos en un archivo de registro local y ver el archivo más tarde. Otro es temporalmente agregar encabezados HTTP reflejando los datos y variables que se está depurando.

Yo regularmente añadir encabezados HTTP, como X-fubar-somevar: o X-pruebas-someresult: para probar cosas - y han encontrado una gran cantidad de errores que de otra manera habría sido muy difícil de trazar.

Iteramos.com

Iteramos es una comunidad de desarrolladores que busca expandir el conocimiento de la programación mas allá del inglés.
Tenemos una gran cantidad de contenido, y también puedes hacer tus propias preguntas o resolver las de los demás.

Powered by:

X