рвер. Перед ним появится список сообщений, первым из которых 
будет его собственное. Пока вроде бы все верно. И теперь пользователь, ничего 
не 
подозревая, нажимает на кнопку Обновить в браузере, заставляя последний, как он 

думает, перезагрузить страницу гостевой книги. 
Но в действительности происходит совсем не то, что он ожидает. Если данные 
формы 
были посланы методом POST, браузер выведет на экран диалоговое окно запроса 
примерно такого содержания: "Вы пытаетесь обновить данные страницы, которая 
была сгенерирована с применением метода POST. Повторить отправку данных (да 
или нет)?" Если пользователь нажмет кнопку Нет, то гостевая книга не 
перезагрузит- 
ся, а появится совершенно бесполезная стандартная страница с сообщением о том, 
что "данные устарели". Если же он подтвердит вторичную отправку данных, его со- 

общение будет добавлено в книгу еще раз, а потому "размножится". Довольно не- 
трудно понять, почему так происходит: ведь браузер "не знает", что в 
действительно- 
сти пользователь хочет лишь вторично "зайти" на адрес страницы книги, а не 
повторить отправку всех данных формы. 
Однако ситуация становится еще плачевнее, если мы применяем в нашей гостевой 
книге метод GET. В этом случае при нажатии на кнопку Обновить браузер "без лиш- 

них разговоров" пошлет данные формы на сервер повторно, так что сообщение будет 

лишний раз добавлено в гостевую книгу без предупреждений. И это тоже понятно: 
ведь метод GET — не что иное, как простое изменение URL страницы, а именно, до- 

бавление в его конец символа ?, после которого следуют параметры (в том числе 
текст записи). 
Впрочем, метод GET практически никогда не применяется в интерактивных сце- 
нариях, таких как гостевые книги, форумы и т. д. Мы уже говорили в первой 
части книги на эту тему, но она настолько важна, что я повторюсь. Если для 

Часть V. Приемы программирования на PHP 502 
одних и тех же данных формы при их многократной отправке страница все- 
гда выглядит одинаково, значит, эти данные логично передавать методом 
GET. В противном случае необходимо применять метод POST. Такое поло- 
жение вещей связано также и с тем, что некоторые proxy-серверы могут кэши- 
ровать страницы, полученные методом GET, но они никогда не кэшируют их 
при использовании POST. 
Самопереадресация — это как раз то средство, которое позволяет разрешить рас- 
смотренный конфликт в сторону пользователя. В самом деле, предположим, что при 
получении уведомления о новом сообщении генератор данных вставляет их в базу 
данных, а затем посылает браузеру заголовок, заставляющий его перезагрузить 
стра- 
ницу гостевой книги. В этом случае страница уже не будет представлять собой ре- 

зультат работы метода POST, это будет обычный HTML-документ, загруженный с 
сервера, как будто бы пользователь считал файл только что самостоятельно и 
"вруч- 
ную". Неудивительно, что кнопка браузера Обновить будет работать так, как ей и 
положено. 
Впрочем, при использовании самопереадресации очень легко наткнуться на один не- 

приятный "подводный камень". Это — ошибка некоторых версий браузера Netscape, 
заключающаяся в том, что