Сабж. Пробовал ставить редирект при помощи headers 301 303 и т.п., в ie все работало на ура, однако... браузер для мобильного телефона нокИя  совершенно справедливо отказался забыть содержимое POST запроса при редиректе и при нажатии кнопки обновить стабильно высылает его скрипту. Ввиду того что ожидать от разработчиков ПО разумных действий при разработке веб-браузеров невозможно в принципе, все данные методы по отсылке заголовков являются недействительными и рано или поздно дадут сбой. Плюс, существует еще такая кнопка как "Назад".

Отсюда вопрос - как грамотно организовать блокировку повторных POST запросов на логическом уровне? Наверняка с этой проблемой кто-либо сталкивался и не раз...

Проблема в том, что запросы, одинаковые по содержанию, в принципе, могут и не являться "повторными". А регистрация времени отправки запроса и последующее сравнение будет давать сбои при большом количестве пользователей. Спасибо.

Это сообщение отредактировал(а) Drkwv - 20.8.2006, 18:02

phpclub.ru/faq/ProblemsLocations

Ха! не все браузеры одинаково полезны. На предложение пойти в Location: телефонный браузер перенаправляет POST - запрос в этот самый Location. Я же говорю - они все ненормальные, эти разработчики.. там такая муть творится....

Добавлено @ 19:32 
А можно еще два раза по кнопке сабмита стукнуть и тогда Location не поможет (и скрипты еще отключить, чтобы disabled не сработал)   

Drkwv, и что? Пускай отправляет свой запрос на скрипт, на который он переправлен. Главное что он еще отправляет POST запрос на скрипт прописанный в action.

Главная цель избежать случайной повторной отправки, header-location прекрасно с этим справляется.
А если пользователь задасться целью специально повторно отправить данные, то ты его никак не остановишь 

А мы делаем так
Запрос перенаправляем на dispatcher.php, dispatcher.php записиваеть $_POST в $_SESSION['post'] и перенаправливаеть скрипт куда эму надо. И там уже нету POST-запроса, так что далнейшая работа вполне безопасная

Всегда помогал header( "Location: ..." ); exit;...
Или я  не совсем верно задау понял.

Mal Hack, ага. Человек же как раз об этом и говорит, что браузер плевал на хедер локейшн и вместе с редиректом отдает пост-данные...

Интересный случай... Ща подумаем... 

Что за браузер у нокиа? Ссылку на сайт дайте.

Э... ну эт смотря какая нокия...
В последних моделях они заюзали вебкит  если это ни о чем не говорит, то я скажу:
вебкит - "яблочный"(apple)  движок для браузеров сафари. Основан на KHTML из KDE(популярный *nix WinManager) + свои патчи...

[HTTP_USER_AGENT] => Nokia6030/2.0 (y3.44) Profile/MIDP-2.0 Configuration/CLDC-1.1   На сайте нокиа об этом ничего не упоминается, видимо им стыдно 

Подумал что надо хешировать мессагу или ее часть, сливая хеш с timestamp'ом подло записанным в hidden input и когда-нибудь, когда полтора миллиарда китайцев одновременно зайдет на сайт и че-нить односложное напишет, процентов 70 из них отфильтруется. Поэтому надо еще проверять ip и не дай бог они станут заходить через proxy %) задача решения не имеет до тех пор пока невозможно абсолютно точно идентифицировать пользователя 

Впрочем, можно для проверки использовать session_id и записывать туда содержимое POST с timestamp и тогда все будет совсем зашибись, правда мне запускать сессию для всех подряд зашедших пользователей не нравится и поисковики беситься будут, но это мелочи а cookies можно отключить поэтому их использовать нельзя. решение задачи жутко некрасивое ))

Это сообщение отредактировал(а) Drkwv - 21.8.2006, 22:03

Drkwv, опиши подробнее, что делает эта Нокиа.

при перенаправлении - неважно с каким заголовком, переносит содержимое POST запроса на перенаправляемый скрипт. При нажатии кнопки "назад" делает то же самое.

т.е. у нас есть страница с формой form.php, из формы данные отсылаются на action.php, и затем происходит перенаправление на redirect.php
А нокия отправляет данные на action.php, а потом ещё на redirect.php. Я правильно понял?

Предлагаю решение:

Шаг 1 :
В сессию пишем переменную-хеш от таймстампа+session_id (тут как фантазия подскажет)
и её же дописываем в форму, в хайден поле. выводим форму.

Шаг 2 :
Нам пришел POST? проверяем его хайден с нашей переменной из сессии, если совпало, выполняем че надо и сносим в сесси переменную