Unified handling of HTTP error pages

Last Updated on Dimanche, 24 octobre 2010 01:53 Written by Henri Gomez Dimanche, 24 octobre 2010 09:31

In configuration with a front Apache HTTPd 2.2.x server and backend Tomcat servers, you may have defined customs error page on the HTTPd configuration using ErrorDocument directive.

ErrorDocument 401 /errors/err-401.html
ErrorDocument 403 /errors/err-403.html
ErrorDocument 404 /errors/err-404.html
ErrorDocument 500 /errors/err-500.html

It works well for resources handled by HTTPd but errors for contents served by Tomcat are still handled by Tomcat error mecanism.

Imagine a web application myapp, served by a Tomcat behind HTTPd, you could have the following setup.

JkMount  /myapp/* worker1

If someone hit an inexisting page, ie /myapp/myfaultypage, you’ll get back the 404 error from Tomcat but not the one defined in HTTPd.

Since version 1.2.27, mod_jk could handle such situation via uriworkermap use_server_errors directive.

But if you don’t want to change your current setup, ie using JkMount, you could use the following :

JkMount  /myapp/* worker1;use_server_errors=400

If Tomcat allready handle Page Not Found, 404, and you only wan’t to see Apache HTTPd handling error greater than or egal to 500, just use :

JkMount  /myapp/* worker1;use_server_errors=500

Thanks to Mladen for the trick

Qui veut la mort de mod_jk ?

Last Updated on Jeudi, 11 décembre 2008 05:51 Written by Henri Gomez Jeudi, 11 décembre 2008 05:51

mod_jk, c’est le module apache permettant de relier un serveur HTTP Apache ou un IIS à un ou plusieurs containeurs de servlet.

Pour cela il faut que le containeur possède un connecteur AJP 1.3 et c’est le cas de Tomcat, Jetty ou Resin.

L’idée initiale dans ce connecteur était de garder une connexion TCP/IP permanente entre le frontal HTTP et le containeur afin de réduire les temps de latences induits par la création d’une connexion à chaque requête HTTP.

Ce module permet aussi d’attacher une grappe de containeurs derrière le frontal avec des mécaniques de répartitions de charge et de tolérance de panne.

Pour avoir ‘trempé’ dans son developpement, je reconnais qu’il n’est pas des plus simples en interne.

Primo il est ancien et date d’avant la disponibilité d’APR, on trouve donc des tonnes de #define et #ifdef pour gérer tel ou tel os.

Ensuite il supporte plusieurs frontaux HTTP, Apache 1.3, 2.0 et 2.2 ainsi qu’IIS.

On a souvent reprocher à sa documentation d’être incomplète, j’aurais pour ma part tendance à dire qu’elle est trop riche.

Il y bien eu une tentative se réecriture en utilisant APR (mod_jk2) mais elle n’a pas aboutie faute de developpeurs à plein temps.

On est donc avec une version 1.2.27 qui est toujours maintenue par quelques personnes efficaces et dans le modèle original OpenSource, des bénévoles.

Vous lirez ici et là que mod_jk est mort remplacé par un mod_proxy avec ou sans support ajp. La force de ce module est d’etre livré avec un Apache 2.0 et 2.2 car il est dans le projet httpd.

Du coup aucune compilation nécessaire pour avoir ce module. C’est toujours ça de gagné.

Un autre projet, initié par Jboss, me semble plus intéressant dans l’optique d’un remplacement de jk. Ce projet c’est mod_cluster qui part de base neuves et possède la capacité. De ‘decouvrir’ la typologie des containeurs.

Le rève de tout administrateur qui souhaite pouvoir monter et démonter à chaud des instances de containeurs semble avoir à modifier la configuration de son/ses frontaux Apache.

Un projet à suivre mais en attendant je recommanderais chaudement de conserver les configurations jk actuelles.

Je publierais des bulletins pour expliquer les configurations jk d’une version hyper simple à des cas plus complexes.

A bientôt