pagina - ¿Código de estado HTTP apropiado para la solicitud que especifica el encabezado de codificación de contenido no válido?

http/1.1 200 ok (2)

¡Deberían hacer de eso la pregunta final sobre Quién quiere ser millonario!

Bueno, el navegador hizo una solicitud de que el servidor no puede atender porque la información que proporcionó el cliente está en un formato que no puede ser manejado por el servidor. Sin embargo, esto no es culpa del servidor por no admitir los datos que el cliente proporcionó, es culpa del cliente por no escuchar los encabezados Acccept- * del servidor y proporcionar datos en una codificación inadecuada. Eso lo convertiría en un error de cliente (código de error de la serie 400).

Mi primer instinto es 400 Bad Request es la respuesta adecuada en este caso.
405 Método no permitido no es correcto porque se refiere a que el verbo HTTP es uno que no está permitido.
406 No aceptable Parece que podría ser prometedor, pero se refiere a que el servidor no puede proporcionar datos al cliente que satisface los encabezados de solicitud Aceptar * que envió. Esto no parece que encajaría en tu caso.
412 Precondition Failed está bastante vagamente definido. Podría ser apropiado, pero no apostaría en ello.
415 El tipo de medio no admitido no es correcto porque no se está rechazando el tipo de datos, es el formato de codificación.

Después de eso entramos en el ámbito de los códigos de respuesta no estándar.

La entidad no procesable 422 describe una respuesta que se debería devolver si la solicitud estaba bien formada pero si era semánticamente incorrecta de alguna manera. Esto parece un buen ajuste, pero es una extensión WebDAV para HTTP y no es estándar.

Teniendo en cuenta lo anterior, yo personalmente optaría por 400 Bad Request. Sin embargo, si algún otro experto en HTTP tiene un mejor candidato, los escucharía. ;)

ACTUALIZACIÓN : anteriormente había estado haciendo referencia a los estados HTTP desde su página en Wikipedia. Si bien la información allí parece ser precisa, tampoco es exhaustiva. Mirar las especificaciones de W3C proporciona mucha más información sobre HTTP 406, y me está llevando a pensar que 406 podría ser el código correcto después de todo.

10.4.7 406 No es aceptable
El recurso identificado por la solicitud solo es capaz de generar entidades de respuesta que tienen características de contenido no aceptables según los encabezados de aceptación enviados en la solicitud.
A menos que sea una solicitud HEAD, la respuesta DEBE incluir una entidad que contenga una lista de las características de la entidad disponibles y la ubicación (es) desde la cual el usuario o el agente de usuario puede elegir la más adecuada. El formato de la entidad está especificado por el tipo de medio dado en el campo de encabezado Content-Type. Dependiendo del formato y las capacidades del agente de usuario, la selección de la opción más apropiada PUEDE realizarse automáticamente. Sin embargo, esta especificación no define ningún estándar para dicha selección automática.
Note: HTTP/1.1 servers are allowed to return responses which are not acceptable according to the accept headers sent in the request. In some cases, this may even be preferable to sending a 406 response. User agents are encouraged to inspect the headers of an incoming response to determine if it is acceptable.
Si la respuesta podría ser inaceptable, un agente de usuario DEBERÍA suspender temporalmente la recepción de más datos y consultar al usuario para tomar una decisión sobre otras acciones.

Si bien menciona el encabezado Content-Type explícitamente, la redacción menciona "características de la entidad", que podría leerse como material de cobertura como GZIP versus la compresión DEFLATE.

Una cosa que vale la pena notar es que la especificación dice que puede ser apropiado simplemente enviar los datos como están, junto con los encabezados para decirle al cliente en qué formato está y qué codificación usa, y dejar que el cliente lo resuelva. . Entonces, si el cliente envía un encabezado que indica que acepta la compresión GZIP, pero el servidor solo puede generar una respuesta con DEFLATE, el envío junto con los encabezados indicará que DEFLATE debería estar bien (según el contexto).

Cliente: Dame una página GZIPPED.
Servidor: Lo siento, no se puede hacer. Puedo envolverlo por usted. Aquí está la página empaquetada DEFLATE. ¿Está bien para ti?
Cliente: Welllll ... Realmente no quería DEFLATE, pero puedo decodificarlo bien, así que lo tomaré.

(o)

Cliente: Creo que tendré que aclararlo con mi usuario. Espere.

¿Qué código de estado se debe devolver si un cliente envía una solicitud HTTP y especifica un encabezado de codificación de contenido que no puede ser descodificado por el servidor?

Ejemplo

Un cliente envía los datos JSON a un recurso REST y codifica el cuerpo de la entidad utilizando la codificación gzip. Sin embargo, el servidor solo puede decodificar las codificaciones DEFLATE porque falló la clase gzip en la escuela del servidor.

¿Qué código de respuesta HTTP debe devolverse? Yo diría que 415 tipo de medio no admitido, pero no es el tipo de contenido de la entidad el problema, es la codificación del cuerpo de la entidad de otro modo compatible.

¿Cuál es más apropiado: 415? 400? Quizás un código de respuesta personalizado?

Anexo: Por supuesto, he verificado minuciosamente el rfc2616. Si la respuesta está ahí, es posible que necesite algunas gafas correctivas nuevas, pero no creo que lo sea.

Actualizar:

Esto no tiene nada que ver con el envío de una respuesta que pueda ser inaceptable para un cliente. El problema es que el cliente está enviando al servidor lo que puede o no ser un tipo de medio válido en una codificación que el servidor no puede entender (según el encabezado de Content-Encoding el cliente empaquetado con el mensaje de solicitud).

Es un caso extremo y no se encontraría al tratar con los agentes de usuario del navegador, pero podría surgir en las API REST que aceptan los cuerpos de las entidades para crear / modificar recursos.

Mientras lo leo, 415 Unsupported Media Type suena como el más apropiado.

De RFC 2616:

10.4.16 415 Tipo de soporte no compatible
El servidor se niega a atender la solicitud porque la entidad de la solicitud está en un formato que el recurso solicitado no admite para el método solicitado.

Sí, la parte del texto dice "tipo de medio" en lugar de "codificación", pero la descripción real no incluye ninguna mención de esa distinción.

El nuevo hotness, RFC 7231 , es incluso explícito al respecto:

6.5.13. 415 tipo de soporte no compatible
El código de estado 415 (Tipo de medio no compatible) indica que el
El servidor de origen se niega a atender la solicitud porque la carga útil
se encuentra en un formato no compatible con este método en el recurso de destino.
El problema de formato puede deberse a lo indicado por la solicitud.
Tipo de contenido o Codificación de contenido , o como resultado de la inspección de
datos directamente