Pouvons-nous créer des codes d'état HTTP personnalisés?

92

J'ai un service REST et WCF et je souhaite envoyer un code d'état personnalisé en fonction de l'opération.

Exemple lorsqu'une validation échoue, je veux envoyer HTTP 444 et lorsque l'autorisation échoue, je veux envoyer HTTP 455

La question est de savoir comment le faire valider pour les services Web SOAP et REST.

Sur le client, comment agit le code d'erreur, car lorsque vous envoyez un HTTP 400/500 à partir d'un service WCF (à l'aide de SOAP), une exception est lancée sur le client affichant le code d'état.

Maintenant, si j'envoie un nouveau code de statut personnalisé, comment le client gère-t-il cela?

c#  asp.net  wcf  http  wcf-rest 
— Rajesh
source
3
Est-ce un service que vous exposez au monde ou contrôlez-vous également tous les clients?
— Rup

Réponses:

109

Oui, tant que vous respectez la classe - c'est-à-dire 2xx pour le succès, 4xx pour l'erreur du client, etc. Vous pouvez donc renvoyer des codes d'erreur 4XX personnalisés (de préférence ceux qui ne sont pas attribués) pour les conditions d'erreur de votre propre application.

Pour citer la [RFC 2616] [1]:

"Les codes d'état HTTP sont extensibles. Les applications HTTP ne sont pas obligées de comprendre la signification de tous les codes d'état enregistrés, bien qu'une telle compréhension soit évidemment souhaitable. Cependant, les applications DOIVENT comprendre la classe de tout code d'état, comme indiqué par le premier chiffre, et traiter toute réponse non reconnue comme étant équivalente au code d'état x00 de cette classe, à l'exception qu'une réponse non reconnue NE DOIT PAS être mise en cache. Par exemple, si un code d'état non reconnu de 431 est reçu par le client, il peut supposer en toute sécurité qu'il y a eu quelque chose ne va pas avec sa demande et traitez la réponse comme si elle avait reçu un code d'état 400. "

Classe'

  • 1xx: informationnel - demande reçue, processus continu

  • 2xx: Succès - L'action a été reçue, comprise et acceptée avec succès

  • 3xx: Redirection - Une action supplémentaire doit être entreprise afin de terminer la demande

  • 4xx: Erreur du client - La requête contient une mauvaise syntaxe ou ne peut pas être satisfaite

  • 5xx: Erreur du serveur - Le serveur n'a pas réussi à répondre à une demande apparemment valide [1]:

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

— ChrisNY
source
2
N'utilisez pas de codes d'état non enregistrés, sauf pour les tests.
— Julian Reschke
1
ChrisNY: eh bien, si vous comptez sur des codes de statut non enregistrés dans votre utilisation de HTTP, il peut y avoir une rupture si quelqu'un d'autre utilise le même code dans un but différent. Si vous avez besoin d'informations d'erreur plus détaillées, vous pouvez toujours l'intégrer dans la charge utile (voir par exemple tools.ietf.org/html/draft-nottingham-http-problem-06 )
— Julian Reschke
21
@ChrisNY: La plupart des applications Web sont conçues pour fonctionner avec un seul client (votre code javascript / ajax) et un seul serveur (votre serveur), donc l'utilisation d'un code d'état personnalisé est tout à fait acceptable. Dans ces situations, il n'est même pas possible pour «quelqu'un d'autre» de provoquer une «rupture» en utilisant le même code d'état.
— AR
2
Cette citation ne dit pas que vous pouvez créer vos propres codes, mais que votre application n'a pas besoin de savoir ce qu'est chaque code enregistré tant qu'elle respecte la classe de code et génère une erreur pour un 4xx, etc. le seul problème que j'ai pu voir est qu'à l'avenir, l'un de ces codes est officiellement attribué et la fonctionnalité du navigateur / javascript pourrait changer. Par exemple, l'attaque 494 DDNS arrête toute communication, le navigateur peut le voir et empêcher js de lancer d'autres communications vers cette adresse IP. Très improbable mais vous ne pouvez pas être à 100%, Twitter semble penser que c'est correct de faire 420 Enhance Your Calm
— Matt
1
La spécification dit que vous pouvez créer vos propres codes et utilise le code 471 comme exemple. Il dit de supposer que toute erreur 4xx non reconnue équivaut à 400.
— Jeff Lowery
32

Je recommande de ne pas créer vos propres codes d'état HTTP, lorsque des codes applicables existent déjà pour les choses que vous souhaitez faire dans votre exemple.

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

Le code d'état 422 [Unprocessable Entity] signifie que le serveur comprend le type de contenu de l'entité de demande (par conséquent, un code d'état 415 [Unsupported Media Type] est inapproprié) et que la syntaxe de l'entité de demande est correcte (donc un 400 [Bad Request ] le code d'état est inapproprié) mais n'a pas pu traiter les instructions contenues. Par exemple, cette condition d'erreur peut se produire si un corps de requête XML contient des instructions XML bien formées (c'est-à-dire syntaxiquement correctes), mais sémantiquement erronées.

On peut faire valoir que "impossible de traiter" pourrait être dû à une erreur de validation.

— Julian Reschke
source
10
L'échec d'autorisation est 401, pas 403. 403 est interdit, là où l'autorisation ne résoudrait pas le problème.
— Neil Hickman
6
401 concerne l'échec de l' authentification (malgré le nom).
— Julian Reschke
1
401 est "Veuillez vous connecter (à nouveau)"
— CodesInChaos
19

Oui, vous pouvez ajouter des codes d'erreur personnalisés. Si possible, utilisez des codes qui existent déjà, et si vous en déclarez de nouveaux, veillez à éviter les collisions.

Sachez cependant que certains proxys filtrent les codes inconnus . J'ai eu des problèmes avec les utilisateurs qui se trouvaient derrière des proxys qui mappaient 5XX à 500 et 4XX à 404. Cela a fait que mes appels ajax échouaient à vérifier le code d'état.

— fmsf
source
oui, les procurations sont nulles. Je ne connais pas le nom de l'implémentation du proxy, mais il a interprété un de nos codes de statut personnalisé et n'a pas envoyé la réponse au client.
— asgs
16

Certaines applications ajoutent leurs codes de réponse personnalisés dans la plage 600-799. Vérifiez par exemple la liste des codes de réponse de KeyNote ici

Codes d'erreur définis par 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).

Si c'est une bonne pratique, je n'oserais pas le dire, mais c'est au moins une référence intéressante.

— Se flétrir
source
1
Ces valeurs sont illégales, dans la mesure où la spécification HTTP n'autorise rien en dehors de 100 ... 599.
— Julian Reschke
16
@JulianReschke J'ai même mentionné que je "n'ose pas dire si c'est une bonne pratique". J'ajoute simplement une référence à ce que font les autres applications. Voter ma réponse parce que Keynote utilise des codes de statut illégaux semble injustifié. Je ne fais qu'alimenter la discussion.
— Wilt
-12

Non, vous ne pouvez utiliser que le code des exigences de documentation rfc, voir les détails dans RFC1945

— Aimeast
source
4
Vous pouvez utiliser n'importe quel code d'état défini dans iana.org/assignments/http-status-codes .
— Julian Reschke
@Julian, cela signifie-t-il que Rajesh peut utiliser les "427-499 non attribués" à ses fins?
— IrishChieftain
OK alors :-) Vous pouvez utiliser n'importe quel code d'état attribué à partir de cette liste. Ou vous écrivez une spécification pour un nouveau code d'état et enregistrez-le.
— Julian Reschke
5
Vous pouvez, techniquement, utiliser ce que vous voulez. Ne vous attendez pas à ce qu'il joue bien avec quelqu'un d'autre. Comme demandé dans le PO - si Rajesh contrôle tous les clients, il peut leur faire comprendre "1337 - Toutes vos bases nous appartiennent" cela leur plaît. ;)
— Cornelius
1
Vous avez lié aux codes d'état HTTP / 1.0, qui n'ont pas été utilisés depuis le début des années 90.
— andsens
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.