Ошибка Apache / Tomcat-неправильные страницы доставляются

может ли это быть потокобезопасность ваших сервлетов?

ваши сервлеты хранят любую информацию в членах экземпляра.

например, что-то простое, как следующее, может вызвать проблемы, связанные с потоками:

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
         }
     }
}

поскольку serlvet доступен несколькими потоками, нет никакой гарантии, что член экземпляра действия не будет заблокирован кем-то запросом elses и в конечном итоге отправит неправильную страницу назад.

простое решение эта проблема заключается в использовании локальных переменных insead членов экземпляра:

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
         }
     }
}

Примечание: это распространяется и на страницы JavaServer, если вы отправляли им свои представления?

Проверьте, позволяют ли ваши заголовки кэшировать без правильного Vary HTTP-заголовок (Если вы используете куки-файлы сеанса, например, и разрешаете кэширование, вам нужна запись в Vary HTTP-заголовок для заголовка cookie или кэш / прокси могут служить кэшированной версией страницы, предназначенной для одного пользователя другому пользователю).

проблема может быть не с кэшированием на вашем веб-сервере, а на другом уровне кэширования (либо на обратном прокси-сервере перед вашим веб-сервером, либо на прокси-сервере рядом пользователь.) Если клиенты используют NAT, они также могут находиться за прозрачным прокси-сервером (и, чтобы сделать вещи еще более трудными для отладки, прозрачный прокси-сервер может быть настроен так, чтобы не быть видимым в заголовках).

8 обновления вопроса позже еще одна проблема для тестирования / воспроизведения, хотя это может быть сложно (или дорого) для публичных сайтов.

вы можете включить HTTPS на сайтах. Это, по крайней мере, уничтожит любые другие кэши прокси по пути. Было бы плохо видеть, что есть некоторые забытые loadbalancers или тайники компании на пути, которые мешают вашему трафику.

для публичных сайтов это будет означать доверенные сертификаты на ключах, поэтому некоторые деньги будут заниматься. Для проверки самоподписанных ключей может быть достаточно. Кроме того, проверьте, что нет прозрачного прокси-сервера, который расшифровывает и повторно шифрует трафик. (они легко обнаруживаются, поскольку они не могут использовать тот же сертификат/ключ, что и исходный сервер)

хотя вы упомянули, что mod_cache не был включен в вашей установке, для других, кто мог столкнуться с той же проблемой с mod_cache включен (даже на статическом содержимом), решение состоит в том, чтобы убедиться, что следующая директива включена в HTTP-заголовке Set-Cookie:

CacheIgnoreHeaders Set-Cookie

причина в том, что mod_cache кэширует заголовок Set-Cookie, который может быть подан другим пользователям. Затем это приведет к утечке идентификатора сеанса от пользователя,который последним заполнял кэш другому.

У меня была эта проблема, и это действительно сводило меня с ума. Я не знаю, почему, но я решил отключить Keep Alive на http.conf

с

KeepAlive On

до

KeepAlive Off

мое приложение не использует функцию keepalive, поэтому он работал очень хорошо для меня.

попробуйте это:

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

посмотрите на этот сайт, он описывает проблему с mod_jk. Я подошел к вашему сообщению, глядя на очень похожую проблему. В основном исправление заключается в обновлении до более новой версии mod_jk. У меня еще не было возможности реализовать изменения на нашем сервере, но я собираюсь попробовать это завтра и посмотреть, поможет ли это.

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

Я не специалист, но это может быть какой-то странный Преобразование Сетевых Адресов вопрос?

Это может быть не проблема кэширования на всех. Попробуйте увеличить параметр MaxClients в apache2.conf. Если он слишком низкий (150 по умолчанию?), Apache начинает очередь запросов. Когда он решает обслуживать запрос в очереди через mod_proxy, он вытаскивает неправильную страницу (или, может быть, это просто подчеркнуто, делая все очереди).

вы уверены, что это страница, которую кто-то просил или страница без параметров?, вы можете получить странные ошибки, если ваш connectionTimeout слишком короткий на сервере.xml на сервере tomcat за apache, увеличьте его до большего числа:

конфигурация по умолчанию:

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

изменено:

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