Définissant à la fois de message d'erreur et le corps de la servlet

Je veux écrire une servlet qui sera de retour une réponse http:

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

<longer custom message>

La raison est que je veux de programmation client pour être en mesure de traiter le message de réponse à une réponse, mais je tiens également à remplir le corps de la réponse avec une explication plus longue, de sorte qu'il est facile de frapper à l'aide d'un navigateur.

Maintenant, HttpServletResponse a un sendError(int, String) méthode qui me permet de spécifier le code d'erreur et un message. La javadoc seulement dire que le message sera intégré dans une page html, mais rien de plus sur le message de réponse http. Après l'appel de cette méthode, vous n'êtes pas autorisé à écrire quoi que ce soit d'autre à la réponse. Dans mes tests (avec jetty), le message est utilisé à la fois pour la réponse http et html du corps, ce qui serait bien avec moi, sauf que je tiens à préciser deux chaînes et je ne pense pas que le paramètre du message de réponse http est garanti grâce à une mise en œuvre différente.

Il y a aussi un setStatus(int) méthode que vous pouvez appeler avec le code, et ensuite vous pouvez écrire votre propre code html de corps. C'est très proche, sauf que vous ne pouvez pas spécifier le message de réponse http.

Enfin, il y a un setStatus(int, String) méthode qui fait exactement ce que je veux, mais c'est déconseillé en raison d'une sorte d'ambiguïté. Je suis en supposant que certains conteneurs de servlet ont écrit le message pour le corps de la réponse et de la fermeture de la réponse.

À part en utilisant la méthode dépréciée, je suis en supposant que je suis vissé ici, mais je suis curieux de savoir si quelqu'un d'autre connaît toutes les astuces?

OriginalL'auteur Jeremy Huiskamp | 2010-10-07

Il y a aussi un setStatus(int) méthode que vous pouvez appeler avec le code, et ensuite vous pouvez écrire votre propre code html de corps. C'est très proche, sauf que vous ne pouvez pas spécifier le message de réponse http.

Est-il une raison pourquoi vous ne devriez pas utiliser response.setStatus(500) pour définir le code d'état HTTP, suivie par écrit à la réponse du flux de sortie?

C'est comment écrire pour le corps de la réponse" est réalisé au niveau le plus bas.

Voici un exemple:

public class ErrorServlet extends HttpServlet {

    @Override
    protected void service(HttpServletRequest req, HttpServletResponse resp)
        throws ServletException, IOException {

        //500 error
        resp.setStatus(HttpServletResponse.SC_INTERNAL_SERVER_ERROR);
        resp.getWriter().print("<html><head><title>Oops an error happened!</title></head>");
        resp.getWriter().print("<body>Something bad happened uh-oh!</body>");
        resp.getWriter().println("</html>");
    }
}

web.xml:

<web-app>
    <servlet>
        <servlet-name>myerror</servlet-name>
        <servlet-class>brown.testservlet.ErrorServlet</servlet-class>
    </servlet>
    <servlet-mapping>
        <servlet-name>myerror</servlet-name>
        <url-pattern>/myErrorPage</url-pattern>
    </servlet-mapping>
</web-app>

Et la sortie:

$ curl -I http://localhost:8080/testservlet/myErrorPage  
HTTP/1.1 500 Internal Server Error  
Content-Length: 108  
Server: Jetty(6.1.16)  

$ curl -v http://localhost:8080/testservlet/myErrorPage
* About to connect() to localhost port 8080 (#0)
*   Trying 127.0.0.1... connected
* Connected to localhost (127.0.0.1) port 8080 (#0)
> GET /testservlet/myErrorPage HTTP/1.1
> User-Agent: curl/7.20.0 (i686-pc-mingw32) libcurl/7.20.0 OpenSSL/0.9.8k zlib/1.2.3
> Host: localhost:8080
> Accept: */*
>
< HTTP/1.1 500 Internal Server Error
< Content-Length: 108
< Server: Jetty(6.1.16)
<
<html><head><title>Oops an error happened!</title></head><body>Something bad happened uh-oh!</body></html>
* Connection #0 to host localhost left intact
* Closing connection #0

Oui, la partie de ma question que vous avez cité les états que je comprends cette option. Il souligne également que cela ne vous autorise pas à définir le message de réponse http ("Erreur Interne du Serveur" dans votre exemple, qui est automatiquement fourni par le conteneur de servlet).
Même si response.setStatus(int, String) est obsolète, vous doit être capable de l'utiliser pour définir l'état de la ligne de message

OriginalL'auteur matt b

5

Vous pouvez personnaliser les pages d'erreur en précisant l'erreur des pages spécifiques web.xml:
```
<error-page>
  <error-code>500</error-code>
  <location>/error500.jsp</location>
</error-page>
```
Dans le fichier jsp, vous pouvez utiliser les attributs de la requête pour afficher un message personnalisé et d'autres infos.

Merci, c'est un excellent point et serait probablement aider la plupart des gens avec ce problème 🙂 je passe à l'aide d'embedded jetée sans l'ensemble du web de configuration de l'application: c'est complètement indépendante de la servlet. Je peux au moins fouiner pour voir si l'erreur de la page peut être en quelque sorte le programme d'installation dans le code, mais je vais probablement régler sur programmatique appelants il suffit de regarder dans le corps pour plus de détails.
Je voulais juste dire à une mise en garde que je suis tombé à travers. Si vous essayez d'utiliser une page html au lieu d'une page jsp, le serveur n'envoie pas le bon code d'état, bien que la page d'erreur de contenu sera affiché.

OriginalL'auteur FRotthowe
1

Eh bien, désolé, la raison la plus évidente pour avoir un corps pour une réponse d'erreur est de montrer quelque chose de lisible par 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 sendError dans la Servlet spec.

Dans mon cas, je veux quelque chose de différent, parce que je suis la création de services web, et ce béton, on ne retourne pas une réponse si tout fonctionne bien.

OriginalL'auteur Juan
1

À l'aide de JBoss 6 je suis venu à la conclusion que le code de réponse doit être définie une fois que vous appelez getWriter pour désactiver le Jboss page d'erreur personnalisée de réponse. Je suppose que la mise en œuvre fournit différents auteurs selon le statut de la réponse.
```
response.getWriter().print(message);
response.setStatus(500);
```
OriginalL'auteur Elijah
1

Semble que tous les Api conçu pour le réglage de la raison, de la phrase dans HTTP deviennent obsolètes à cause de cela:

RFC 7230, Protocole de Transfert Hypertexte (HTTP/1.1): la Syntaxe du Message de Routage et de, juin 2014. La Section 3.1.2:

La raison-phrase élément existe dans le seul but de fournir de l'
une description textuelle associée avec le code numérique,
la plupart du temps hors de la déférence à l'antérieures d'Internet protocoles d'application
qui ont été les plus fréquemment utilisées pour le texte interactif clients. Un
le client DOIT ignorer la raison-la phrase de contenu.

Tomcat supprimé le support org.apache.coyote.USE_CUSTOM_STATUS_MSG_IN_HEADER propriété dans version 8.5.0.

Merci. À ce stade, je ne me souviens plus exactement pourquoi j'ai voulu un client pour être en mesure d'inspecter la raison de la phrase, mais il ne semble pas que c'était une très bonne idée.

OriginalL'auteur Jarekczek
0

Si vous voulez avoir un message d'erreur personnalisé dans les en-têtes, pourquoi ne pas ajouter votre propre en-tête avec response.addHeader(String, String)? En combinant ceci avec matt b de la réponse pourrait faire le travail.

OriginalL'auteur nash

Vous devez vous connecter pour publier un commentaire.