HttpServletResponse#encodeRedirectURL добавляет JSESSIONID (url-rewriting) для запроса перенаправления.
Мне было интересно, это имеет смысл, если мы перенаправляемся на другой сервлет в нашем веб-приложении, верно?
В противном случае, если мы перенаправляемся на другой сервер, как можно создать JSESSIONID, который мы создали на нашем сервере, для использования на другом сервере?Значение идентификатора сеанса для другого сервера?
Вы правы. Идентификатор сеанса имеет смысл только для данного webapp. Вот почему Javadoc говорит:
Зашифровывает указанный URL для использования в способе sendRedirect или если кодирование не требуется, возвращает URL неизменным. Реализация этот метод включает в себя логику для определения того, должен ли идентификатор сеанса кодироваться в URL.
(курсив мой)
Итак, мы используем этот метод только для перенаправления * в * наших веб-приложениях. Знаете ли вы об общем случае использования? – Cratylus
[post-redirect-get pattern] (http://en.wikipedia.org/wiki/Post/Redirect/Get) является основным прецедентом. –
В Java EE контейнер приложения отвечает за управление сеансом и по умолчанию использует файлы cookie.
Эта ссылка Under what conditions is a JSESSIONID created? имеет подробное объяснение по поводу JSESSIONID и как она создана.
Обратитесь также к этому сообщению http://javarevisited.blogspot.in/2012/08/what-is-jsessionid-in-j2ee-web.html
Как это относится к моему вопросу? – Cratylus
Как можно создать JSESSIONID, который мы создали на нашем сервере, на другом сервере? , это объясняется в сообщении, попробуйте прочитать его, вместо этого спрашивая –
. Мой вопрос касается конкретного API. И утверждение 'как может JSESSIONID, который мы создали на нашем сервере, использовать на другом сервере?' является частью мои предположения в моем OP.Пожалуйста, прочитайте вопросы перед ответом – Cratylus
Скажем, у вас есть кластер: несколько серверов с тем же набором приложений, развернутых последовательно (даже одного приложения).
JSESSIONID (будь то в куки или закодирован в URL) устанавливается на один сервер может быть полезным для другого сервера в этом кластере, если сессия кластеризация включена, так же приложение на другом сервере может ответить на пользовательский запрос, используя ее данные сеанса, первоначально сохраненные на первом сервере, или даже дополнение этих же данных сеанса.
Обычно лучше перенаправить на тот же сервер, если он установлен, для локализации данных, чтобы ограничить болтовню в кластере.
См
Я думаю, что этот ответ неполный после прочтения комментариев @ JBNizet.I думаю, что это должно быть сформулировано: 'JSESSIONID (будь то в файле cookie или закодирован в URL) может быть полезным для другого сервера в кластерной среде для перенаправления на конкретное веб-приложение'. Как вы думаете? – Cratylus
Это не вопрос перенаправления. Кластеризация сеансов позволяет высокодоступному заявлению с состоянием, так как любой запрос (перенаправление или нет) будет отвечать на любой сервер в кластере (который, конечно же, имеет такое же приложение). Если один из серверов опускается, его пользователи не остаются без сеанса. –
Да, это то, что я имею в виду. Эта часть вашего последнего комментария: 'cluster (у которого такое же приложение развернуто, конечно)' Я думаю, что это необходимо в вашем ответе. – Cratylus
Другой сервер не сможет понять JSESSIONID вашего разъединяет. Только ваш сервер сможет сопоставить jsessionid. Надежда ниже справочной информации поможет вам;
Я думаю, что вы имели в виду «это имеет смысл только если мы перенаправлять ** тот же сервер **», regardlesss сервлета. –
@FrankPavageau: Почему сеанс «разделяется» между веб-приложениями? – Cratylus
@Cratylus: нет, это не так. Но webapp может быть сгруппирован между несколькими серверами, поэтому все они используют одни и те же сеансы. Итак, важно, что Webapp, а не сервер. –