Erreur Apache / Tomcat-mauvaises pages livrées

pourrait-il S'agir de la sécurité de vos servlets?

vos servlets stocker toutes les informations dans les membres de l'instance.

par exemple, quelque chose d'aussi simple que ce qui suit peut causer des problèmes liés au fil:

public class MyServlet ... {
    private String action;

    public void doGet(...) {
         action = request.getParameter("action");
         processAction(response);
    }

    public void processAction(...) {
         if (action.equals("foo")) {
             // send foo page
         } else if (action.equals("bar")) {
             // send bar page
         }
     }
}

parce que le serlvet est accessible par plusieurs threads, il n'y a aucune garantie que le membre de l'instance d'action ne sera pas bloqué par une requête de quelqu'un d'autre, et finira par renvoyer la mauvaise page.

la solution simple à ce problème est d'utiliser des variables locales en tête des membres de l'instance:

public class MyServlet ... {
    public void doGet(...) {
         String action = request.getParameter("action");
         processAction(action, response);
    }

    public void processAction(...) {
         if (action.equals("foo")) {
             // send foo page
         } else if (action.equals("bar")) {
             // send bar page
         }
     }
}

Note: Ceci s'étend aussi aux Pages JavaServer, si vous les expédiiez pour vos vues?

vérifiez si vos en-têtes autorisent la mise en cache sans l'en-tête HTTP Vary correct (si vous utilisez des cookies de session, par exemple, et autorisez la mise en cache, vous avez besoin d'une entrée dans l'en-tête HTTP Vary pour l'en-tête cookie, ou un cache/proxy pourrait servir la version mise en cache d'une page destinée à un utilisateur à un autre utilisateur).

le problème pourrait ne pas être avec la mise en cache sur votre serveur web, mais sur une autre couche de mise en cache (soit sur un proxy inverse en face de votre web serveur, ou sur un proxy près de l'utilisateur). Si les clients se comportent comme un NAT, ils pourraient aussi être derrière un proxy transparent (et, pour rendre les choses encore plus difficiles à déboguer, le proxy transparent pourrait être configuré pour ne pas être visible dans les en-têtes).

8 mises à jour de la question plus tard, un autre numéro à utiliser pour tester/reproduire, bien qu'il puisse être difficile (ou coûteux) pour les sites publics.

vous pouvez activer https sur les sites. Cela éliminerait au moins toutes les autres caches proxies en cours de route. Ce serait dommage de voir qu'il y a des équilibres oubliés ou des caches de compagnie sur le chemin qui interfèrent avec votre trafic.

pour les sites publics cela impliquerait des certificats de confiance sur le touches, donc de l'argent. Pour tester les clés auto-signées pourrait suffire. Aussi, Vérifiez qu'il n'y a pas de mandataire transparent impliqué qui décrypte et réencrypte le trafic. (ils sont facilement détectables, car ils ne peuvent pas utiliser le même certificat/clé que le serveur d'origine)

bien que vous ayez mentionné que mod_cache n'était pas activé dans votre setup, pour les autres qui ont rencontré le même problème avec mod_cache activé (même sur les contenus statiques), la solution est de s'assurer que la directive suivante est activée sur L'en-tête HTTP Set-Cookie:

CacheIgnoreHeaders Set-Cookie

la raison étant que mod_cache cache l'en-tête Set-Cookie qui peut être servie à d'autres utilisateurs. L'ID de session de l'utilisateur qui a rempli le cache pour la dernière fois serait alors divulgué à un autre utilisateur.

j'ai eu ce problème et ça m'a vraiment rendu dingue. Je ne sais pas pourquoi, mais je l'ai résolu en désactivant le Keep Alive sur le http.conf

de

KeepAlive On

à

KeepAlive Off

mon application n'utilise pas la fonctionnalité keepalive, donc ça a très bien fonctionné pour moi.

essayez ceci:

response.setHeader("Cache-Control", "no-cache"); //HTTP 1.1
response.setHeader("Pragma", "no-cache"); //HTTP 1.0
response.setDateHeader("Expires", 0); //prevents caching at the proxy server

Regardez ce site, il décrit un problème avec mod_jk. Je suis venu à travers votre affectation tout en regardant une question très similaire. Fondamentalement, la solution consiste à mettre à jour vers une nouvelle version de mod_jk. Je n'ai pas encore eu la chance d'implémenter le changement dans notre serveur, mais je vais essayer ça demain et voir si ça aide.

http://securitytracker.com/alerts/2009/Apr/1022001.html

Je ne suis pas un expert, mais est-ce que ça pourrait être un problème bizarre traduction de L'adresse réseau ?

C'est peut-être pas un problème de mise en cache à tous. Essayez d'augmenter le paramètre MaxClients dans apache2.conf. Si elle est trop faible (150 par défaut?), Apache commence à mettre les requêtes en file d'attente. Quand il décide de servir la requête mise en file d'attente via mod_proxy il sort une mauvaise page (ou peut-être il est juste stressé en faisant toute la file d'attente).

Êtes-vous sûr que c'est la page que quelqu'un d'autre demande ou une page sans paramètres?, vous pourriez avoir des erreurs bizarres si votre connectionTimeout est trop court sur le serveur.xml sur le serveur tomcat derrière apache, augmentez - le à un plus grand nombre:

configuration par défaut:

  <Connector port="8080" protocol="HTTP/1.1"
               connectionTimeout="20000"
               redirectPort="8443" />

modifié:

  <Connector port="8080" protocol="HTTP/1.1"
               connectionTimeout="2000000"
               redirectPort="8443" />