HTTP 400 (solicitud incorrecta) de error lógico, no sintaxis de solicitud malformada

Question

los Especificación HTTP/1.1 (RFC 2616) tiene lo siguiente que decir sobre el significado de Código de estado 400, solicitud incorrecta (§10.4.1):

El servidor no pudo entender la solicitud debido a la sintaxis malformada. El cliente no debe repetir la solicitud sin modificaciones.

Parece haber una práctica general entre unas pocas API basadas en HTTP en estos días para usar 400 para significar un lógico preferible a sintaxis Error con una solicitud. Supongo que las API están haciendo esto para distinguir entre 400 (inducido por el cliente) y 500 (inducido por el servidor). ¿Es aceptable o incorrecto usar 400 para indicar errores no sintácticos? Si es aceptable, ¿hay una referencia anotada en RFC 2616 que proporcione más información sobre el uso previsto de 400?

Ejemplos:

• Protocolo de datos de Google, referencia de protocolo, códigos de estado HTTP

Answer 1

A partir de este momento, el último borrador del Httpbis especificación, que está destinada a reemplazar y hacer que RFC 2616 sea obsoleta, estados:

El código de estado 400 (mala solicitud) indica que el servidor no puede o no procesará la solicitud porque la sintaxis recibida no es válida, sin sentido o excede alguna limitación sobre lo que el servidor está dispuesto a procesar.

Esta definición, aunque, por supuesto, aún está sujeta a cambios, ratifica la práctica ampliamente utilizada de responder a errores lógicos con un 400.

Answer 2

Estado 422 (RFC 4918, Sección 11.2) me viene a la mente:

El código de estado 422 (entidad no procesable) significa que el servidor comprende el tipo de contenido de la entidad de solicitud (de ahí un código de estado 415 (tipo de medio de medio no compatible) es inapropiado), y la sintaxis de la entidad de solicitud es correcta (por lo tanto, un 400 (solicitud incorrecta (mala solicitud ) El código de estado es inapropiado) pero no pudo procesar las instrucciones contenidas. Por ejemplo, esta condición de error puede ocurrir si un cuerpo de solicitud XML contiene instrucciones XML bien formadas (es decir, sintácticamente correctas), pero semánticamente erróneas.

Answer 3

HTTPBIS abordará la redacción de 400 malas solicitudes para que también cubra errores lógicos. Entonces 400 incorporarán 422.

De https://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-18#section-7.4.1
"El servidor no puede o no procesará la solicitud, debido a un error del cliente (por ejemplo, sintaxis malformada)"

Answer 4

Aunque también he estado usando 400 para representar errores lógicos, debo decir que devolver 400 es incorrecto en este caso debido a la forma en que se lee la especificación. He aquí por qué creo que sí, el error lógico podría ser que una relación con otra entidad estaba fallando o no satisfecho y hacer cambios en la otra entidad podría causar que pase exactamente más tarde. Como tratar de agregar (completamente hipotético) a un empleado como miembro de un departamento cuando ese empleado no existe (error lógico). Agregar a los empleados como solicitud de miembro podría fallar porque el empleado no existe. Pero la misma solicitud exacta podría pasar después de que el empleado se haya agregado al sistema.

Solo mis 2 centavos ... necesitamos abogados y jueces para interpretar el lenguaje en el RFC en estos días :)

Gracias Vish

Answer 5

Se podría argumentar que tener datos incorrectos en su solicitud es Un error de sintaxis, incluso si su solicitud real en el nivel HTTP (línea de solicitud, encabezados, etc.) es sintácticamente válida.

Por ejemplo, si un servicio web RESTFUL se documenta como aceptando publicaciones con un tipo de contenido XML personalizado de application/vnd.example.com.widget+xml, y en su lugar envía un texto plano de Gibberish o un archivo binario, parece resasonable tratar eso como un error de sintaxis: su cuerpo de solicitud no está en la forma esperada.

Sin embargo, no conozco ninguna referencia oficial para respaldar esto, como de costumbre, parece que se debe a interpretar RFC 2616.

Actualizar: Tenga en cuenta la redacción revisada en RFC 7231 §6.5.1:

El código de estado 400 (mala solicitud) indica que el servidor no puede o no procesará la solicitud debido a algo que se percibe como un error del cliente, por ejemplo, sintaxis de solicitud malformada, encuentro de mensajes de solicitud no válidos o enrutamiento de solicitud de solicitud engañosa).

parece apoyar este argumento más que el ahora obsoletado RFC 2616 §10.4.1 que decía justo:

El servidor no pudo entender la solicitud debido a la sintaxis malformada. El cliente no debe repetir la solicitud sin modificaciones.

Answer 6

En los servidores Java EE A 400 se devuelve si su URL se refiere a una "aplicación web" inexistente. ¿Es eso un "error de sintaxis"? Depende de lo que quiere decir con error de sintaxis. Yo diría que sí.

En inglés, las reglas de sintaxis prescriben ciertas relaciones entre partes del habla. Por ejemplo, "Bob se casa con Mary" es sintácticamente correcto, porque sigue el patrón {sustantivo + verbo + sustantivo}. Mientras que "Bob Matrimonio Mary" sería sintácticamente incorrecto, {sustantivo + sustantivo + sustantivo}.

La sintaxis de un URLIS simple {Protocolo +: + // + Server +: + Port}. De acuerdo a esto "http://www.google.com:80"es sintácticamente correcto.

Pero, ¿qué pasa con "ABC: //www.google.com: 80"? Parece seguir exactamente el mismo patrón. Pero realmente es un error de sintaxis. ¿Por qué? Porque 'ABC' no es un protocolo definido.

El punto es que determinar si tenemos o no una situación de 400 requiere más que analizar los personajes, espacios y delimitadores. También debe reconocer cuáles son las "partes del discurso" válidas.

Answer 7

Esto es difícil.

Pienso que deberíamos;

1. Devuelva los errores 4xx solo cuando el cliente tenga el poder de hacer un cambio en la solicitud, los encabezados o el cuerpo, eso dará como resultado que la solicitud tenga éxito con la misma intención.

2. Códigos de rango de error de retorno Cuando la mutación esperada no ha ocurrido, es decir, un eliminación no ocurrió o una put no cambió nada. Sin embargo, una publicación es más interesante porque la especificación dice que debe usarse para crear recursos en una nueva ubicación o simplemente procesar una carga útil.

Usando el ejemplo en la respuesta de Vish, si la solicitud tiene la intención de agregar el empleado Priya a un marketing de departamento, pero Priya no se encontró o su cuenta está archivada, entonces este es un error de aplicación.

La solicitud funcionó bien, llegó a las reglas de su aplicación, el cliente hizo todo correctamente, los ETAG, etc., etc.

Debido a que estamos usando HTTP, debemos responder en función del efecto de la solicitud en el estado del recurso. Y eso depende de su diseño de API.

Quizás diseñaste esto.

PUT { updated members list } /marketing/members

Devolver un código de éxito indicaría que el "reemplazo" del recurso funcionó; Una obtención del recurso reflejaría sus cambios, pero no lo haría.

Así que ahora debe elegir un código HTTP negativo adecuado, y esa es la parte difícil, ya que los códigos están muy destinados al protocolo HTTP, no a su aplicación.

Cuando leí los códigos HTTP oficiales, estos dos se ven adecuados.

El código de estado 409 (conflicto) indica que la solicitud no podría completarse debido a un conflicto con el estado actual del recurso objetivo. Este código se utiliza en situaciones en las que el usuario podría resolver el conflicto y volver a enviar la solicitud. El servidor debe generar una carga útil que incluya suficiente información para que un usuario reconozca la fuente del conflicto.

Y

El código de estado 500 (error interno del servidor) indica que el servidor encontró una condición inesperada que evitó que cumpliera la solicitud.

Aunque tradicionalmente consideramos que el 500 es como una excepción no controlada:-/

No creo que no sea razonable inventar su propio código de estado siempre que se aplique y diseñe constantemente.

Este diseño es más fácil de tratar.

PUT { membership add command } /accounts/groups/memberships/instructions/1739119

Entonces podría diseñar su API para que siempre tenga éxito en la creación de la instrucción, devuelve 201 creado y un Ubicación El encabezado y cualquier problema con la instrucción se llevan a cabo dentro de ese nuevo recurso.

Una publicación es más como esa última ubicada en una nueva ubicación. Una publicación permite cualquier tipo de procesamiento del servidor de un mensaje, que abre diseños que dicen algo como "la acción falló con éxito".

Probablemente ya escribió una API que hace esto, un sitio web. Usted publica el formulario de pago y fue rechazado con éxito porque el número de tarjeta de crédito estaba mal.

Con una publicación, si devuelve 200 o 201 junto con su mensaje de rechazo depende de si se creó un nuevo recurso y está disponible para llegar a otra ubicación, o no.

Dicho todo esto, me inclinaría a diseñar API que necesiten menos puestos, tal vez solo actualizar los campos de datos, y las acciones y cosas que invocan reglas y procesos o simplemente tienen una mayor probabilidad de fallas esperadas, pueden diseñarse para publicar una instrucción forma.