| |
любые страницы, полученные им в результате самопере-
адресации, он ошибочно принимает за пустые (и соответственно отображает). И все
же выход есть: достаточно немного модифицировать URL страницы, чтобы браузер
"подумал", что это уже другой документ, а не тот же самый. Листинг 33.3
показывает,
как это можно сделать. В целях экономии места я разместил шаблон страницы и ге-
нератор данных в одном файле.
Листинг 33.3. Самопереадресация
// Считываем содержимое базы данных.
$Book=@Unserialize(join("",File("book.dat")));
if(!$Book) $Book=array();
// Проверяем, не нужно ли добавить запись...
if(@$Go) {
array_unshift($Book,$Text);
$f=fopen("book.dat","w");
fwrite($f,Serialize($Book));
fclose($f);
// Внимание! Самопереадресация. Обратите внимание на то,
// какой заголовок мы посылаем.
Header("Location: http://$HTTP_HOST$REQUEST_URI?".time());
exit; // Завершить сценарий.
}
Глава 33. Разные советы 503
?>
$v) {?>
=$v?>
}?>
Мы обеспечиваем "уникальность" URL страницы гостевой книги за счет добавления в
его конец текущего времени в секундах, прошедших с 1 января 1970 года (так
назы-
ваемый Unix timestamp). Вряд ли пользователь будет обновлять страницу чаще, чем
раз в секунду, поэтому такой способ прекрасно подходит для наших целей.
Обратите внимание на то, что в заголовке Location мы передаем полный URL стра-
ницы, включая имя хоста. Большинство браузеров умеют "понимать" и сокращенные
пути (например, без указания имени сервера), но некоторые — нет, так что лучше
не
искушать судьбу.
Запрет кэширования страниц
Изрядное количество сценариев генерируют страницы, которые постоянно изменяют-
ся во времени, поэтому кэширование таких документов, которое иногда пытаются
провести "слишком умные" браузеры и proxy-серверы, следует отключить. В против-
ном случае пользователь может увидеть устаревшие данные и не заметить, что ваша
страница изменилась.
Вообще говоря, если браузер "захочет" сохранять страницу в кэше и затем
постоянно
выдавать пользователю одно и то же, никакая сила не сможет запретить ему делать
это. К счастью, большинство браузеров более "послушны" — они адекватно реагиру-
ют на специальные заголовки запрета кэширования, которые могут присутствовать в
странице, полученной с сервера. То же самое делают и proxy-серверы — правда,
они
используют уже другие заголовки.
В листинге 33.4 приведены четыре заголовка, которые необходимо послать вместе с
телом страницы, чтобы браузеры и proxy-серверы не пытались ее кэшировать. Опыт
подтверждает, что эти 4 заголовка — минимум. Если убрать хотя бы один из них,
некоторые proxy-серверы (или браузеры) могут "не понять", что от них требуется.
Листинг 33.4. Заголовки для запрета кэширования
Header("Expires: Mon, 26 Jul 1997 05:00:00 GMT"); // Дата в прошлом
Часть V. Приемы программирования на PHP 504
Header("Last-Modified: ".gmdate("D, d M Y H:i:s")."GMT"); // Изменилась
Header("Cache-Control: no-cache, must-revalidate"); // для HTTP/1.1
Header("Pragma: no-cache"); // для HTTP/1.0
Излишне напоминать, что все заголовки должны быть отправлены до первой коман-
ды вывода в сценарии.
При использовании шаблонизатора наподобие того, который был описан в
главе 30, это требование является необязательным. В таком случае весь ре-
зультат работы сценария и шаблона буферизируется и не отправляется в
браузер до самого последнего момента.
Несколько слов о флажках checkbox
|
|