Mettre le message d'erreur REST détaillé dans l'en-tête http Warning, bonne/mauvaise idée ?

Question

Nous sommes de développement d'une norme de service de REPOS à l'aide de codes d'état HTTP, comme son code de réponse si quelque chose s'est mal passé. (par exemple, entrée utilisateur non valide serait de retour "400 Bad Request" pour le client)

Toutefois, nous avons estimé qu'un message d'erreur plus détaillé serait utile pour le client. (par exemple, l'entrée non valide erreur est due à X étant un paramètre non reconnu de nom)

Nous tenons à être le plus fidèle à l'adresse HTTP specs que possible, donc après l'étude de la spécification dans la RFC2616, nous envisageons de mettre le message d'erreur détaillé dans les en-Têtes HTTP, en particulier sur l' en-tête HTTP de la zone d'alerte. Il a dit sur la RFC:

L'Avertissement général-champ d'en-tête est utilisé pour transporter des informations supplémentaires sur le statut ou la transformation d'un message qui pourrait ne pas être reflétés dans le message. Cette information est généralement utilisé pour avertir d'un éventuel manque de transparence sémantique à partir de la mise en cache des opérations ou transformations appliquées à l'entité corps du message.

Il semble y avoir aucune restriction sur l'utilisation de cet en-tête pour d'autres mises en garde (comme le RESTE de message d'erreur), même ceux qui sont sans rapport avec le cache avertissements que par l'intention originale de cet en-tête. Nous aimons la sémantique, et nous avons prévu d'utiliser l'299 avertissement de code, ce qui semble correspondre au projet de loi assez bien:

299 Divers persistante avertissement Le texte d'avertissement PEUVENT inclure arbitraire de l'information afin d'être présentées à un utilisateur humain, ou connecté. Un système de réception de cet avertissement NE DOIT prendre aucune des mesures automatisées.

Donc, compte tenu de l'entrée non valide erreur de cas présentées sur le haut de cette question, nous envisageons de mettre notre REPOS message d'erreur semblable à l'exemple suivant:

HTTP/1.1 400 Bad Request
Warning: 299 ServiceName "Invalid input error: X is unrecognized parameter name."

Est-ce une bonne idée ou pratique? Nous avons également constaté que certains services détaillée de ce message à X-Avertissement de la tête, mais ce ne semble pas être la norme. Nous sommes demandé ce qui serait la ruche sagesse de stackoverflow RESTE de la foule pensez à ce sujet. Est-il aussi mieux/une pratique courante pour la transmission des messages d'erreur dans le RESTE de réponses?

Answer 1

Pourquoi ne pas simplement changer la phrase de raison? C'est pour ça qu'il est là. Le texte "Mauvaise Demande" n'est que la valeur par défaut. Si vous souhaitez inclure plus d'informations, utilisez le corps de réponse. La spécification HTTP dit que vous devez inclure un organisme de réponse avec les détails d'une erreur.

Answer 2

Où que vous mettiez vos commentaires, que ce soit dans le corps du message (contenu) ou dans un en-tête d'avertissement, veillez à ne pas donner d'informations qui pourraient être utiles à un attaquant effectuant des tests de pénétration sur votre système.

Parfois, moins d'infos est mieux.

Answer 3

Je suis en faveur de l'approche générale. Nous devons supposer que le développeur client est dans une autre équipe du service de développeur, peut-être dans un autre fuseau horaire, etc. Peut-être même d'une société différente. C'est pas bon juste retour d'un "non c'est un bad request" réponse, comment le client peut-il résoudre le problème.

Si philosophiquement: dire les clients sur les choses qu'ils ont une responsabilité à corriger. Les erreurs qui sont purement de la portée du serveur (par exemple. connexion de base de données d'erreur, ou de certains problème de logique) c'est juste pour retourner une erreur 500. Et ici, je ne voudrais pas envoyer de détail, nous ne voulons pas exposer les détails de notre la mise en œuvre interne pour le client.

Jusqu'à maintenant j'ai été renvoyer des données dans le corps de la réponse, à l'aide de JAX/RS:

return Response.status(400).entity("some message here").build();

Je pense que votre utilisation des en-têtes peuvent être en fait un nettoyant appraoch.

Answer 4

Si cette proposition est acceptée, elle présente une alternative pour l'envoi de messages d'erreur détaillés. [http://tools.ietf.org/html/draft-nottingham-http-browser-hints]

Bien qu'il soit un I-D, il est assez stable ces derniers temps, et je ne vois aucun problème avec la construction de votre propre implémentation. (J'ai fait.)