Utilisez la page d'erreur personnalisée pour la page 404 de Tomcat lors de l'utilisation de mod_jk et Apache httpd


Fabricant de baguette

Nous avons une configuration comme celle-ci:

httpd <-> mod_jk (Tomcat)

httpd est configuré pour transférer toutes les requêtes vers l'URL / application * vers mod_jk. httpd est configuré avec des pages d'erreur personnalisées pour les erreurs HTTP 404, 500, etc.

Si l'utilisateur entre une URL, http://hostname/non-existing-page- la page d'erreur 404 personnalisée de httpd s'affiche.

Si l'utilisateur entre l'URL, http://hostname/app-blabblah- la page d'erreur 404 de Tomcat s'affiche. L'application hébergée sur / app peut traiter des erreurs 404 s'il s'agit de quelque chose comme / app / inexistantepage. Mais context / app-blablah ne se résout en aucun fichier de guerre sur Tomcat, et entraîne donc la page d'erreur 404 de Tomcat.

Nous utilisons une version allégée de Tomcat, son dossier Webapps n'en contient que app.war.

On m'a demandé de ne pas afficher la page d'erreur Tomcat 404 car elle révèle le fait que l'application est hébergée sur Tomcat et affiche également la version de Tomcat.

Si quelqu'un peut me dire comment:

  1. Ajoutez une page d'erreur 404 personnalisée pour Tomcat lorsqu'il doit gérer des URL qui représentent un contexte non existant.
  2. Ou configurez httpd de telle sorte que s'il voit que Tomcat renvoie une erreur 404, il restitue sa propre page d'erreur 404 personnalisée.

PS: Je ne suis pas libre de pointer uniquement / app / * vers mod_jk, car nous déployons parfois d'autres guerres qui commencent par app à des fins de débogage - par exemple app-debug.war.

Mise à jour: je modifie mod_jk workers.properties pour transférer uniquement / app / * vers Tomcat.

fabuleux

Pour répondre à ta question :

  1. Ajoutez une page d'erreur 404 personnalisée pour Tomcat lorsqu'il doit gérer des URL qui représentent un contexte non existant.

Et en respectant votre contrainte initiale:

Je ne suis pas libre de pointer uniquement / app / * vers mod_jk, car nous déployons parfois d'autres guerres qui commencent par app à des fins de débogage - par exemple app-debug.war.

La solution la plus simple consiste à utiliser un dossier webapp ROOT. Cependant, et pour respecter votre autre condition pour garder votre dossier webapps minimaliste, vous n'avez rien à conserver dans votre dossier webapp ROOT mais votre page d'erreur personnalisée .

Avec cette configuration, il vous suffit d'ajouter votre $ CATALINA_BASE / conf / web.xml

<error-page>
  <error-code>404</error-code>
  <location>/general-error.html</location>
</error-page>

Ou tout ce qui correspond le mieux à ce que vous voulez. (Ici, vous pouvez utiliser la même page personnalisée d'erreur que votre app.war et les utilisateurs finaux ne verront pas la différence).


Le résultat est :

Situation 1: http://hostname/non-existing-page

  • La page personnalisée d'erreur httpd sera affichée

Situation 2: http://hostname/app/non-existing-page

  • La page personnalisée d'erreur de votre application app.war s'affiche. ($ CATALINA_BASE / conf / web.xml puis $ CATALINA_BASE / webapps / app / WEB-INF / web.xml sont utilisés)

Situation 3: http://hostname/app-dummy-url

  • La page personnalisée d'erreur Tomcat de votre dossier ROOT s'affiche. (Seul $ CATALINA_BASE / conf / web.xml est utilisé).

Lors de l'édition, vous avez supprimé votre contrainte et êtes désormais capable de:

chang (e) mod_jk workers.properties pour transférer uniquement / app / * à Tomcat.

Eh bien dans cette configuration, vous aurez le même résultat que l'alternative que vous vouliez:

  1. Ou configurez httpd de telle sorte que s'il voit que Tomcat renvoie une erreur 404, il restitue sa propre page d'erreur 404 personnalisée.

Mais si vous souhaitez toujours utiliser un fichier war de débogage tel que vous l'avez mentionné dans votre question (app-debug.war), vous devrez modifier votre configuration httpd (worker.properties et probablement également vos VirtualHosts) à chaque fois et / ou laisser déboguer configuration dans ces fichiers. Comme cela ne semble pas approprié pour un environnement de production, l'utilisation d'un dossier ROOT dans Tomcat ne contenant que des pages personnalisées semble la meilleure solution ici IMO.

Articles connexes