De RFC2616 Sec4.2:
campo
Cada cabecera consiste en un nombre seguido de dos puntos (":") y el valor del campo.
A primera vista, esto parecería poner mensajes que especifiquen valores de encabezado vacíos en la categoría mal formada, no conforme. Sin embargo, la forma BNF aumentada indica en RFC2616 Sec2.1 indica que
"#element" permite a cualquier número, incluyendo el cero
Como se trata de la declaración se usa para especificar valores de la cabecera Accept, parece que los valores vacíos son validos.
Analizar cabeceras vacías y cabeceras con nada más que un espacio en blanco puede ser problemático debido a la siguiente dirección de la especificación:
El campo de contenido no incluye ninguna LWS iniciales o finales: lineal espacio en blanco que ocurre antes el primer carácter que no sea de espacio en blanco del valor de campo o después del último carácter que no sea de espacio en blanco del valor de campo . Tal LWS principal o posterior PUEDE eliminarse sin cambiando la semántica del valor del campo. Cualquier LWS que se produzca entre el contenido de campo PUEDE ser reemplazado por un único SP antes de interpretar el valor del campo o reenviar el mensaje en sentido descendente.
En mi humilde opinión, enviar un encabezado vacío es completamente inútil. No se debe hacer, y los analizadores pueden no analizar correctamente estos encabezados.Tradicionalmente, las personas que quieren eludir dichas limitaciones cuando se trata de componentes no conformes han especificado valores de "pseudo-vacío" como esto:
X-MyCustomHeader: ""
Si simplemente quiere validar que un campo de cabecera fue enviado como algunos forma de cambio booleano, considere enviar un valor de marcador de posición como el anterior en lugar de un valor vacío.
actualización
supongo que no estaba muy claro en responder directamente a la pregunta: en el caso de una cabecera Accept vacío que realmente tiene dos opciones:
- Enviar un
406 Not Acceptable respuesta para informar al cliente que no ofrece ningún tipo de contenido para un valor de Aceptar vacío (duh).
Esto se justifica, pero no requerido por RFC2616 Sec14.1:
Si un campo de cabecera Aceptar está presente, y si el servidor no puede enviar una respuesta que es aceptable de acuerdo con la Aceptar valor de campo combinado , entonces el servidor DEBERÍA enviar una respuesta 406 (no aceptable).
- O, porque esto no es necesario y es muy poco probable que el usuario no acepta ningún tipos de contenido (de lo contrario, ¿por qué molestarse para enviar la solicitud?) ... Yo sugeriría tratar un valor
Accept: vacío (si el rechazo de mensaje no es una opción) igual que Accept: */*.
No estoy de acuerdo en que los encabezados vacíos estén mal formados, especialmente porque la propia especificación hace referencia a los encabezados vacíos (ver mi ejemplo de Aceptar codificación). Para dar contexto, estoy desarrollando el middleware web python y pensando en eventualidades y cómo probar en contra de ellos. Fui por asumir '' */* '', lo cual me parece razonable también. ¡Gracias por tomarse el tiempo! –
También creo que '' 400 Bad Request'' sería más apropiado que '' 406 Not Acceptable'', al menos si suponemos que esto es una violación de la especificación. Porque en ese caso, no pudimos averiguar qué es lo que el cliente realmente acepta. –
Ya sabe, tiene razón acerca de 2616-2.1 - el formulario '# elemento' indica que los valores de encabezado vacíos son correctos. Voy a actualizar mi respuesta para reflejar esto y evitar información errónea. Además, creo que esto hace que sea una respuesta 406 -o bien- tratarlo como 'Aceptar: */*' válido. Pero probablemente no sea un 400 ya que técnicamente no es un mensaje inválido. – rdlowrey