Code HTTP pour les applications non démarrées

Bonjour,
Voici mon problème: j'ai un webservice REST en Java sur Tomcat qui est accédé par des processes automatiques. Ces processes demandent des informations sur des objets métiers et prennent des actions en conséquence.
Notamment, lorsque l'objet métier demandé n'est pas disponible, le webservice retourne le code HTTP 404.
Le problème est que Tomcat retourne également 404 lorsque la webapp en question n'est pas démarrée. C'est logique du point de vue de tomcat, mais pas du point de vue de l'application cliente: d'un point de vue plate-forme globale, il est "normal" d'avoir un objet métier non trouvé, mais il est anormal de ne pas avoir la webapp qu'on demande (quelle qu'en soit la raison, crash, maintenance, etc.). De ce point de vue, il serait plus adéquat que tomcat retourne un code HTTP 5xx (500, 501, 503).
La question est donc: est-il possible de dire à Tomcat de retourner un 50x au lieu d'un 404 lorsqu'une webapp demandée n'est pas disponible?
Merci pour votre aide,
Emmanuel
PS: la version de tomcat est la 6.0.24

Tomcat non démarré devrait... être en mesure de retourner quelque chose???? :marteau:

En pure Tomcat, non, tu ne peux rien faire... une appli non démarrée ne peut rien retourner... Par contre, la solution est de mettre en place un reverse proxy Apache, et en jouant avec la config, tu pourras retourner un code d'erreur plus parlant... Par exemple, un 503 - Service Unavailable qui est fait pour...

C'est de toute façon plutôt une bonne pratique de cacher Tomcat (ou n'importe quel serveur JEE) derrière un proxy...

Hello Pill_S,

Merci pour ta réponse, mais je pense que je me suis mal exprimé: Tomcat est bien démarré, mais pas la webapp qu'il hoste.

Imaginons que mon tomcat possède 2 webapp: mywebapp1 (démarrée) et mywebapp2 (non démarrée).
1. Si je demande http://myhost/mywebapp1/index.jsp, j'aurai le résultat de index.jsp, puisque la webapp est démarrée.
2. Si je demande http://myhost/mywebapp2/index.jsp, Tomcat est bien up mais me retournera un 404 puisque la webapp n'est pas démarrée => Ma question est de savoir si on peut forcer tomcat à retourner 503 dans ce cas précis uniquement.

Merci,
Emmanuel

Hello,

j'en doute fortement... On peut lire ici: http://tomcat.apache.org/tomcat-8.0-...er-howto.html:

Citation:

---

Stop an Existing Application

http://localhost:8080/manager/text/stop?path=/examples
Signal an existing application to make itself unavailable, but leave it deployed. Any request that comes in while an application is stopped will see an HTTP error 404, and this application will show as "stopped" on a list applications command.

---

... ils ne laissent pas vraiment entendre que c'est quelque chose de configurable...

De toute façon, tu auras beaucoup plus de souplesse avec un Apache frontal, à la limite qui saura si un chemin est légal ou pas et qui saura retourner un 404 ou un 503...

A noter aussi, que certains outils, comme http://www.modsecurity.org/rules.html, font justement de la réécriture de codes http afin de rendre la tâche plus difficile aux intrus (ie. il n'est pas fondamentalement faux d'avoir du 404 par défaut, que la resources soit indisponible, non trouvée, ou non autorisée)...

Salut,

J'imagine que ce n'est pas possible de forcer Tomcat à changer sa réponse..

Mais si c'est dans le cas de test automatique, tu peux toujours avant de lancer le test sur ton objet, faire un GET sur une Servlet de ton application qui te retourne un message prédéfini (genre "coucou c'est moi!") et qui, en cas d’erreur 404 te permet toi d'en déduire que ton service n'est pas accessible.

En gros tu ping une servlet avant de lancer ton test.

Edit : Bon en fait c'est con puisque tu auras le même résultat si Tomcat n'est pas démarré et tu auras le même problème dans l'autre sens..

Bonjour,

Une solution qui m'a été proposée est la suivante: déclarer une webapp ROOT qui réponde 503 à toutes les requêtes sur l'ensemble du Tomcat. Si Tomcat est démarré avec cette application, on aura 503. Si on démarre une webapp sur un contexte donné, alors ce contexte va surcharger la webapp root et répondre normalement. Et si cette webapp est arrêtée, alors on récupèrera le 503.
Qu'en pensez-vous?
Merci

Emmanuel

J'en pense que c'est un hack, et que, comme tout hack, même si ça marche, c'est une mauvaise idée... il se passe quoi si par mégarde on supprime la webapp root? si le tomcat se plante?

En fonction de ton besoin et du contexte, ça peut suffire... Mais la seule vraie bonne réponse, qui restera valide quel que soit le contexte et le niveau d'exigence en terme de qualité, c'est le proxy...

Pas sûr de comprendre: mon besoin n'est pas la sécurité, mais applicatif: mon tomcat héberge un webservice appelé par un process automatique, qui doit adopter un comportement A si le webservice est up&running mais que la ressource demandée n'est pas disponible, et un comportement B si la webapp n'est pas démarrée.
Et je ne vois pas comment un proxy pourra lui-même faire la différence entre les deux.
Donc on peut que c'est un hack (encore que je ne contourne pas les fonctionnalités de tomcat, l'override de contexte est prévu), mais je ne suis pas sûr d'avoir beaucoup de choix, si?

un proxy n'est pas là que pour la sécurité... mais peut faire tout un tas de choses, notamment de la translation de code http (souvent dans le but de cacher des détails d'implémentation à un attaquant potentiel, mais on peut imaginer d'autres use case)...

Tu t'es jamais demandé comment un site web arrivait à afficher une belle page d'erreur "Ce site est actuellement en maintenance blabla" si justement le serveur d'appli était down? bin c'est le (reverse) proxy qui gère ça...

Le coup de la webapp sur / peut fonctionner, mais je trouve ça moche. Et ne résout rien en cas de maintenance sur le tomcat (là tu te prendras un 404, pas moyen de changer ça sans proxy). C'est pour ça que je trouve ça hacky... ça couvre pas 100% des cas, c'est une utilisation détournée d'une webapp, qu'il faut déployer et maintenir, et y'a une solution meilleure et parfaitement adaptée et largement éprouvée par plein de monde depuis longtemps...

Mais au final, tu fais comme tu veux hein!!