¿Podemos crear códigos de estado HTTP personalizados?

92

Tengo un servicio REST y WCF y quiero enviar un código de estado personalizado basado en la operación.

Ejemplo, cuando falla alguna validación, quiero enviar HTTP 444 y cuando falla la autorización, quiero enviar HTTP 455

La pregunta es cómo lo tenemos validado para los servicios web SOAP y REST.

En el cliente, ¿cómo actúa el código de error? Porque cuando envía un HTTP 400/500 desde un servicio WCF (usando SOAP), se lanza una excepción al cliente que muestra el código de estado.

Ahora, si envío un nuevo código de estado personalizado, ¿cómo maneja esto el cliente?

c#  asp.net  wcf  http  wcf-rest 
— Rajesh
fuente
3
¿Es este un servicio que estás exponiendo al mundo o también controlas a todos los clientes?
— Rup

Respuestas:

109

Sí, siempre que respete la clase, es decir, 2xx para el éxito, 4xx para el error del cliente, etc. Por lo tanto, puede devolver códigos de error 4XX personalizados (preferiblemente aquellos que no están asignados) para las condiciones de error de su propia aplicación.

Para citar de [RFC 2616] [1]:

"Los códigos de estado HTTP son extensibles. No se requiere que las aplicaciones HTTP comprendan el significado de todos los códigos de estado registrados, aunque tal comprensión es obviamente deseable. Sin embargo, las aplicaciones DEBEN comprender la clase de cualquier código de estado, como lo indica el primer dígito, y tratar cualquier respuesta no reconocida como equivalente al código de estado x00 de esa clase, con la excepción de que una respuesta no reconocida NO DEBE almacenarse en caché. Por ejemplo, si el cliente recibe un código de estado no reconocido de 431, puede asumir con seguridad que hubo algo anda mal con su solicitud y trata la respuesta como si hubiera recibido un código de estado 400 ".

Clase'

  • 1xx: Informativo: solicitud recibida, proceso continuo

  • 2xx: Éxito: la acción se recibió, comprendió y aceptó correctamente

  • 3xx: redireccionamiento: se deben realizar más acciones para completar la solicitud

  • 4xx: Error del cliente: la solicitud contiene una sintaxis incorrecta o no se puede cumplir

  • 5xx: Error del servidor: el servidor no pudo cumplir con una solicitud aparentemente válida [1]:

http://tools.ietf.org/html/rfc2616#section-6.1.1

— ChrisNY
fuente
2
No utilice códigos de estado no registrados, excepto para realizar pruebas.
— Julian Reschke
1
ChrisNY: bueno, si confía en códigos de estado no registrados en su uso de HTTP, puede haber una rotura si alguien más usa el mismo código para un propósito diferente. Si necesita información de error más detallada, aún puede incrustarla en la carga útil (consulte, por ejemplo, tools.ietf.org/html/draft-nottingham-http-problem-06 )
— Julian Reschke
21
@ChrisNY: La mayoría de las aplicaciones web están diseñadas para funcionar con un solo cliente (su código javascript / ajax) y un solo servidor (su servidor), por lo que usar un código de estado personalizado está completamente bien. En estas situaciones, ni siquiera es posible que "alguien más" cause una "rotura" utilizando el mismo código de estado.
— AR
2
Esa cita no dice que pueda crear sus propios códigos, sino que su aplicación no necesita saber qué es cada código registrado siempre que respete la clase de código y arroje un error para un 4xx, etc. Aparte de eso, el único problema que pude ver es que en el futuro, uno de estos códigos se asigna oficialmente y la funcionalidad del navegador / javascript puede cambiar. Por ejemplo, el ataque 494 DDNS detiene todas las comunicaciones, el navegador puede ver eso y bloquear js para que no inicie más comunicaciones con esa ip. Muy poco probable, pero no puedes estar al 100%, Twitter parece pensar que está bien hacer 420 Mejora tu calma
— Matt
1
La especificación dice que puede crear sus propios códigos y usa el código 471 como ejemplo. Dice asumir cualquier error 4xx no reconocido como equivalente a 400.
— Jeff Lowery
32

Recomiendo no crear sus propios códigos de estado HTTP, cuando los códigos aplicables ya existen para las cosas que desea hacer en su ejemplo.

De https://tools.ietf.org/html/rfc4918#section-11.2 :

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

Se puede argumentar que "no se puede procesar" podría deberse a un error de validación.

— Julian Reschke
fuente
10
El error de autorización es 401, no 403. 403 está prohibido, donde la autorización no solucionaría el problema.
— Neil Hickman
6
401 se trata de autenticación fallida (a pesar del nombre).
— Julian Reschke
1
401 es "Por favor, inicie sesión (nuevamente)"
— CodesInChaos
19

Sí, puede agregar códigos de error personalizados. Sin embargo, si es posible, use códigos que ya existen, y si está declarando nuevos, tenga cuidado de evitar colisiones.

Sin embargo, debe tener en cuenta que algunos proxies filtran códigos desconocidos . Tuve problemas con los usuarios que estaban detrás de los proxies que asignaban 5XX a 500 y 4XX a 404. Esto hizo que mis llamadas ajax fallaran al verificar el código de estado.

— fmsf
fuente
sí, los proxies apestan. No sé el nombre de la implementación del proxy, pero interpretó un código de estado personalizado nuestro por sí solo y no envió la respuesta al cliente.
— pregunta
16

Algunas aplicaciones agregan sus códigos de respuesta personalizados en el rango 600-799. Consulte, por ejemplo, la lista de códigos de respuesta de KeyNote aquí

Códigos de error definidos por Keynote (600-799)

600: CONNECTION ERROR - This indicates a general connection error
601: INCOMPLETE ERROR - This indicates sever sends an incomplete page/object (as indicated by Content-Length header)
602: UNEXPECTED CLOSE ERROR - This indicates socket connection has been closed unexpectedly
603: REFUSED ERROR - This indicates a request to connect to the server is refused
604: TIMEOUT ERROR - This indicates there is no activity in socket connection in 3 minutes
605: REDIRECT ERROR - This indicates an error in redirect HTTP header
606: SSL ERROR - This indicates a general error in SSL
607: HEADER ERROR - This indicates a malformed HTTP header
608: EMPTY RESPONSE ERROR - This indicates server doesn't send any response after a request is sent
609: UNKNOWN HOST ERROR - This indicates socket receives an unknown host error from DNS
610: NO ROUTE TO HOST ERROR - This indicates a no route to host error was received while attempting to open a socket
611: SOCKET ERROR - This indicates a general socket error
612: FRAME LOOP ERROR - This indicates a page has a frame loop (frame A includes Frame B that includes Frame A)
613: REDIRECT LOOP ERROR - This indicates a page has a redirect loop (page A redirects to page B that redirects to page A)
614: CONNECTION RESET ERROR - This indicates socket receive a reset signal from the server
615: SOCKET PROTOCOL ERROR - This indicates an error in socket protocol
616: SOCKET BIND ERROR - This indicates an error in binding the socket
617: CONNECTION ERROR - This indicates a general socket connection error
618: CHUNK ERROR - This indicates an error in chunked encoding
619: SSL TIMEOUT - This indicates a timeout during SSL handshake (2 minutes)
620: SSL END OF INPUT - This indicates an end-of-file is received during SSL handshake
621: SSL HANDSHAKE ERROR - This indicates a general error during SSL handshake
622: SSL CERTIFICATE ERROR - This indicates an error in SSL certificate verification
623: SSL AUTHENTICATION ERROR - This indicates an authentication error during SSL handshake
624: SSL BAD MAC ERROR - This indicates a bad MAC during SSL handshake
625: SSL CIPHER ERROR - This indicates a cipher error during SSL handshake
701: ERROR TEXT FOUND - This code is returned if any error text (such as, "Service Unavailable") are found in the main page (frame HTML contents included). Note that the error text must be defined in advance of the test. Error text means if the text is found, this session should be considered a failure.
702: REQUIRED TEXT NOT FOUND - This code is returned If not all required texts are found in the main page. Note that required text must be defined in advance of the test. Required text means if the text is not found, this session should be considered a failure.
703: HTML BODY EMPTY - This code is returned if the HTML body of the page is empty (only if error text or required text has been defined).

No me atrevería a decir si esto es una buena práctica, pero al menos es una referencia interesante.

— Marchitar
fuente
1
Esos valores son ilegales, ya que la especificación HTTP no permite nada fuera de 100 ... 599.
— Julian Reschke
16
@JulianReschke Incluso mencioné que "no me atrevo a decir si es una buena práctica". Simplemente agrego una referencia a lo que hacen otras aplicaciones. Votar mi respuesta en contra porque Keynote usa códigos de estado ilegales parece injustificado. Solo estoy alimentando la discusión.
— March
-12

No, solo puede utilizar el código de requisitos de documentación rfc, consulte los detalles en RFC1945

— Aimeast
fuente
4
Puede utilizar cualquier código de estado definido en iana.org/assignments/http-status-codes .
— Julian Reschke
@Julian, ¿esto significa que Rajesh puede usar los "427-499 No asignados" para sus propósitos?
— IrishChieftain
OK, entonces :-) Puede usar cualquier código de estado asignado de esa lista. O puede escribir una especificación para un nuevo código de estado y registrarlo.
— Julian Reschke
5
Técnicamente, puedes usar lo que quieras. No espere que le vaya bien a nadie más. Como se le preguntó en el OP - si Rajesh controla a todos los clientes, puede hacerles entender "1337 - Toda su base nos pertenece" si así lo desean. ;)
— Cornelius
1
Se vinculó a códigos de estado HTTP / 1.0, que no se han utilizado desde principios de los 90.
— andsens el
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.