) Можно послать другой код, означающий что ресурс поменял адрес навечно, но это придется вручную делать и еще не известно, поможет ли.| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Java EE (J2EE) и Spring > Проблема с IE, при response.sendRedirect |
| Автор: Opik 23.1.2007, 17:30 | ||
Всем привет. Сделал авторизацию. после авторизации делаю:
потом уже на новой странице жму (CTRL +R - обновить), в лисе все отлично, обновляется страница и можно работать дальше. в IE же, он пытается заново авторизироваться.(выскакивает окно с подтверждением повторного запроса на отсылку данных, т.е как будто я редирект и не делал). или же надо делать что то ещё помимо вышеуказанной строки? |
| Автор: COVD 23.1.2007, 17:44 |
| а попробуйте убрать request.getContextPath(), вдруг поможет? По умолчанию браузер сам подставляет. |
| Автор: Opik 23.1.2007, 17:49 |
| Не помогло |
| Автор: COVD 23.1.2007, 18:13 |
| значит IE интерпретирует редирект буквально - код 302 означает, что ресурс перемещен временно , т.е. браузер запоминает изначальный адрес (а вдруг этот ресурс постоянно меняет адрес ) Можно послать другой код, означающий что ресурс поменял адрес навечно, но это придется вручную делать и еще не известно, поможет ли. |
| Автор: Opik 23.1.2007, 18:57 |
| COVD, другой это какой? |
| Автор: COVD 23.1.2007, 19:15 |
| http://www.faqs.org/rfcs/rfc2068.html ..... Status-Code = "100" ; Continue | "101" ; Switching Protocols | "200" ; OK .... | "301" ; Moved Permanently | "302" ; Moved Temporarily ..... 301 стало быть. sendRedirect() , если не ошибаюсь, отсылает 302 и новый адрес. Посмотрите, может в sendRedirect есть какие-то опции, чтобы вручную значения хедера не определять. |
| Автор: Stampede 23.1.2007, 19:45 |
| Opik, есть подозрение, что дело в заголовках ответа, управляющих кэшированием в браузере. Но чтобы нам тут не гадать на кофейной гуще, расскажи подробнее, как делаешь авторизацию. Судя по твоему скудному описанию, ты используешь идиому PRG (Post-Redirect-Get), и это правильно. Но все же хотелось бы знать точнее. |
| Автор: Opik 23.1.2007, 20:34 |
| Stampede, Извиняюсь за скудное описание, но так и есть (я про идиому). Т.е заполняю форму, запрос к базе, проверки, если все успешно - редирект |
| Автор: Stampede 23.1.2007, 20:52 |
Можешь привести пример трех адресов:
И главное, при чем тут рефреш? |
| Автор: Opik 23.1.2007, 20:57 | ||
| Stampede, 1) url/login.jsp 2) url/login 3) url/main
нужна возможность обновлять страницу. в лисе все ок, а в ИЕ [censored 6] фигня... |
| Автор: Tony 23.1.2007, 21:40 | ||
Попробуй укажи. |
| Автор: JUncle 23.1.2007, 21:59 | ||||
Так и есть. Может попробовать RequestDispatcher?
|
| Автор: Stampede 23.1.2007, 23:08 |
| Понятно. В принципе все делается правильно. Почему не работает в IE - ХЗ. Заголовки кэширования тут не помогут - не тот случай. Форвард тоже не решение. С форвардом как раз сломается то, что по крайней мере работает в ФФ. Что вызвало к жизни появление темплейта PRG? Как раз проблема рефреша (и перемещения по кнопкам Взад/Вперед) страницы, созданной в ответ на POST. Чтобы ее разрешить, додумались делать так: адрес, по которому происходит POST, не должен вообще появляться в адресной строке браузера! Вместо него должен сразу идти редирект на страницу подтверждения, и браузер повторным запросом, уже по GET, ее наконец получает. Я бы в твоей ситуации сделал вот что. Я бы убедился, что действия сервера и браузера подчиняются протоколу. То есть важно знать, по какому адресу приходит запрос, какой используется метод, GET или POST, какой возвращается код статуса и прочие заголовки ответа. Если у тебя в проге этого не предусмотрено, можно написать фильтр, который будет эту инфу выводить в логи. Кроме того, на стороне браузера можно отследить клиентскую, так сказать, версию происходящего. В лисе для этого есть хороший плагин под названием FireBug. От этого и будем плясать дальше. ЗЫ. Еще одна мысль пришла в голову. Прверить нечем, так как шестой IE отсутствует. Мысль такая: что если адрес для редиректа указывать не относительный, url/main, а полный, http://localhost:8080/url/main. Может, конечно и не поможет, но все-таки... |
| Автор: Opik 24.1.2007, 01:12 | ||||||||
1) Request:
Response:
2) Request:
Response:
Смотрел через httpwatch |
| Автор: Opik 24.1.2007, 02:33 |
| Сделал отправку 301 статуса (Moved Permanently) не помогло |
| Автор: Opik 24.1.2007, 03:19 |
| Уже какие только заголовки не отправлял чего только не мониторил... хз |
| Автор: Stampede 24.1.2007, 03:21 |
| О, вот это уже конкретная инфа! Я полагаю, это запись событий по варианту с IE? Ну что ж, выглядит все правильно. Тогда вот еще что интересно было бы знать: что происходит по рефрешу? Куда и каким методом пытается лезть браузер? И еще. А нет ли у тебя на страницы каких фреймов, явных или скрытых (IFRAME)? И не используешь ли ты XmlHttpRequest? |
| Автор: Opik 24.1.2007, 03:24 | ||
| Stampede, При рефреше идет POST запрос на /main на странице есть фреймы и явные и скрытые. есть и xmlhttprequest (через prototype.js) Добавлено @ 03:24
именно |
| Автор: Stampede 24.1.2007, 11:22 | ||
Блин, вот это уже глюк осла. Если он /main брал GET'ом, то и рефреш должен делать так же. А ты можешь посмотреть, что он еще передает в теле запроса? Формные данные шлет? Если все так, то остается, наверно, только гуглить по теме, а если и это не поможет - писать жалобы Гейцу. Толку никакого, а вроде что-то и предпринял. Вода, как известно, камень точит |
| Автор: Tony 24.1.2007, 12:16 |
| У меня в ИЕ тоzhe били проблемы. Но там был Ajax(prototype.js). Сервер выдавал ресулт а ИЕ кешировал у апдейта не было. Но как только указал парагма 0 и про4ее, всё заработало. |
| Автор: Opik 24.1.2007, 13:43 |
| Stampede, данные шлются тоже. Писать Билли бессмысленно Да и почему только с явой такое? |
| Автор: Opik 24.1.2007, 15:49 |
| Авторизацию переделал на AJAX. И с помощью JS делаю location.href = '/main'; и все работает на ура )))) |
