Dev Faq
9
votes

Fixer à la fois le message d'erreur et le corps du servlet

Je veux écrire un servlet qui retournera une réponse HTTP comme suit: 

HTTP/1.1 500 <short custom message>
Content-Length: ...

<longer custom message>

0 commentaires

6 Réponses :

5
votes

Vous pouvez personnaliser les pages d'erreur en spécifiant des pages spécifiques d'erreur dans web.xml: xxx

dans le fichier JSP, vous pouvez utiliser des attributs de demande pour afficher un message personnalisé et d'autres informations.

2 commentaires

Merci, c'est un excellent point et aiderait probablement la plupart des gens avec ce problème :) J'arrive à utiliser une jetée intégrée sans l'ensemble de l'application Web: il s'agit d'un servlet totalement autonome. Je peux au moins piquer pour voir si la page d'erreur peut être configurée en quelque sorte dans le code, mais je vais probablement vous installer sur les appelants programmatiques vient de regarder dans le corps pour les détails.

Je voulais juste mentionner une mise en garde que j'ai heurtée. Si vous essayez d'utiliser une page HTML au lieu d'une JSP, le serveur n'enverra pas le code d'état correct, bien que le contenu de la page d'erreur soit affiché.

11
votes

Il existe également une méthode SeStatus (int) que vous pouvez appeler avec n'importe quel code, puis vous pouvez écrire votre propre corps HTML. Ceci est proche, sauf que vous ne pouvez pas spécifier le message de réponse HTTP.

Y a-t-il une raison pour laquelle vous n'utiliseriez pas réponse.settatus (500) pour définir le code d'état HTTP, suivi de l'écriture dans le flux de sortie de la réponse?

Ceci est Comment "écrire au corps de réponse" est atteint au niveau le plus bas.

Voici un exemple: xxx

web.xml: < Pré> xxx

et la sortie: xxx

2 commentaires

Oui, la partie de ma question que vous avez citée indique que je comprends cette option. Il souligne également que cela ne vous permet pas de définir le message de réponse HTTP ("" Erreur de serveur interne "dans votre exemple, qui est automatiquement fourni par le conteneur de servlet).

Même si réponse.setStatus (int, chaîne) est obsolète, vous devrait être en mesure de l'utiliser pour définir le message de ligne d'état

2
votes

Si vous souhaitez avoir un message d'erreur personnalisé dans les en-têtes, pourquoi ne pas ajouter votre propre en-tête avec Response.addheader (chaîne, chaîne) ? En combinant cela avec la réponse de Matt B pourrait faire le travail.

0 commentaires
1
votes

Eh bien, désolé, la raison la plus évidente d'avoir un corps pour une réponse d'erreur consiste à montrer quelque chose de lisible à l'homme dans un navigateur lorsqu'une erreur se produit. C'est la raison pour laquelle la génération de HTML est le comportement par défaut de SenderError dans la spécification de servlet.

Dans mon cas, je veux quelque chose de différent, car je crée des services Web, et ce concret ne renvoie pas une réponse si tout fonctionne bien.

0 commentaires
1
votes

Utilisation de JBoss 6 Je suis arrivé à la conclusion que le code de réponse doit être défini après avoir appelé GetWriter pour désactiver la réponse de la page d'erreur personnalisée de JBoss. Je suppose que la mise en œuvre fournit différents écrivains en fonction de l'état de la réponse. 

response.getWriter().print(message);
response.setStatus(500);

0 commentaires
1
votes

semble que toutes les API conçues pour définir la phrase de la raison de HTTP deviennent obsolètes à cause de ceci:

RFC 7230, Protocole de transfert hypertexte (http / 1.1): syntaxe de message et routage , juin 2014. Section 3.1.2 :

L'élément de phrase de la raison existe dans le seul but de fournir une description textuelle associée au code d'état numérique, surtout hors de déférence pour les protocoles d'application Internet précédents qui étaient plus fréquemment utilisés avec des clients de texte interactifs. a Le client doit ignorer le contenu de la phrase de la raison .

TOMCAT Support supprimé pour org.apache.coyote.use_custom_status_msg_in_header propriété dans version 8.5.0 .

1 commentaires

Merci. À ce stade, je ne me souviens plus exactement pourquoi je voulais qu'un client puisse inspecter la phrase de la raison, mais cela ne semble pas être une très bonne idée.

Articles qui pourrait vous intéresser :

Comment envoyer une liste vide à la clause IN
Code de réponse 403 inattendu lors de la récupération des données des API
Impossible de trouver la classe UnityPlayerActivity dans com.unity3d.player
Comment définir un tableau dans jsonobject