На полноту изложения темы я не претендую, это ведь статья, а не справочное пособие, но для начинающих будет вводной информацией в эту технику.
Собственно, о самом термине:
Автоматическое перенаправление пользователя со страницы, на которую он попал на другую страницу или сайт. Технически реализовать редирект можно целым рядом способов.
Данным механизмом следует пользоваться только в исключительных случаях, по той причине, что поисковые системы считают, что редирект может быть использован недобросовестными раскрутчиками, привлекающими таким способом аудиторию на собственый сайт со страниц специально созданных для поисковых машин на страницы действительно содержащие полезный контент, что выглядит как обман поисковиков.
Перед началом повествования сделаю небольшие замечания:
* Вам не обязательно быть PHP-программистом, чтобы разобраться в технике редиректа;
* Подразумевается, что сервер (будь-то локальный - localhost, или же ваш хостинг в интернете) поддерживает выполнение PHP-скриптов.
А вообще, если что будет непонятно, то милости прошу на php.net :)
Суть технологии или техники редиректа - это автоматическое перенаправление кого-то куда-то :) А куда именно - вы сами задаете в скрипте, таким образом, при выполнении скрипта он вас автоматически перенаправит на определенный web-адрес.
Получается, что переход идет не по прямой ссылке с сайта вида <a href="http://www.google.com">google.com</a>, а через скрипт.
1. Открываем любой html-редактор (хотя подойдет и блокнот) и набираем/вставляем в него следующий код:
2. Далее сохраняем наш файл с вышеприведенным кодом, например code.php и загружаем его на веб-сервер. К примеру, если вы загрузили code.php в корневую папку сайта codeguru.com.ua, то вызвать скрипт можно по URL http://www.coders-library.ru/code.php. После исполнения скрипта на сервере вы будете автоматически перенаправлены (средиректены :)) на полезный сайт для программистов realcoding.net - что и было указано в нашем скрипте.
Еще можно просто на сайте в теле страницы (внутри тегов <body>...</body>) поставить ссылку вида:
.
.
Вот такая нехитрая техника редиректа (redirect).
Эта задача возникает для PHP-скриптов вызываемых без параметров или являющимися индексами директорий, однако формирующих данные персонально под пользователя (например на основе cookies или user agent) или работающих на основе быстро изменяющихся данных.
По спецификации HTTP/1.1 мы можем управлять следующими полями:
Expires
Задает дату истечения срока годности документа. Задание ее в прошлом определяет запрет кэш для данной страницы.
Cache-control: no-cache
Управление кэш. Значение no-cache определяет запрет кэш данной страницы. Для версии протокола HTTP/1.0 действует "Pragma: no-cache".
Last-Modified
Дата послднего изменения содержимого. Поле актуально только для статических страниц. Apache заменяет это поле значением поля Date для динамически генерируемых страниц, в том числе для страниц содержащих SSI.
На сайте www.php.net дается следующий код для запрета кеширования.
Однако, я считаю, что данный заголовок избыточен. В большинстве случаев достаточно:
Чтобы пометить документ как "уже устаревший" следует установить Expires равным полю Date.
Ну и не следует забывать, что формы, запрошенные по POST также не подлежат кэшированию.
Для оптимизации работы с сетью используется механизм сохранения однажды полученных по HTTP документов в кеше с целью их повторного использования без обращения к серверу-источнику. Документ, сохраненный в кеше будет доступен при следующем обращении к нему, без выгрузки с сервера-источника, что призвано повысить скорость доступа клиента к нему и уменьшить расход трафика сети.
Сами кэши бываю двух видов - локальные и общие
Локальный это кеш, хранимый непосредственно на диске у клиента, создаваемый и управляемый его браузером. Общий - кэш прокси-сервера организации или провайдера и может состоять из одного или нескольких прокси-серверов. Локальный кеш присутствует, наверное в каждом браузере, общими пользуется значительная часть людей использующих Internet. И если малую часть сайтов сейчас оценивают по расходу трафика, то скорость загрузки - важный критерий, который должен учитываться при разработке Вашего web-проекта.
Для динамических страниц, создаваемых в результате работы PHP-программы, казалось бы, кэширование вредно. Содержание страницы формируются по запросу пользователя на основе какого-либо источника данных. Однако, кэширование может быть полезным. Управляя им Вы можете сделать работу с Вашим сервером комфортнее для пользователя, разрешая загрузку из кэш определенных страниц, предотвращая тем самым их повторную выгрузку с Вашего сервера и экономя пользователю время и трафик.
Кэшировать или нет?
Возможность сохранения в кэш страницы определяется динамичностью информации в источнике данных. Таким образом необходимость использования кэша определяется Вами, исходя из планируемого времени жизни страницы.
Если речь идет о формировании выборки по базе (например, поиск введенного пользователем слова), то такую страница обязательно следует запрашивать с сервера при каждом вызове без использования кэш, так как количество вариантов запрашиваемых слов огромно, а если мы к тому же имеем дело с меняющимся массивом данных, то кэширование бессмысленно. Или речь идет о формировании допустим графика приходящих посетителей (который изменяется с каждым визитом, то есть практически с каждым вызовом), то кеширование уже просто вредно.
Однако, если мы говорим о том же графике но за вчерашний день, то кэширование рекомендуется, так как данные изменяться уже не будут и мы можем экономить себе и пользователю ресурсы и время на загрузку таких страниц помещением их в локальный или общий кэш. Как продолжение этой ситуации формирование графика не в реальном масштабе времени, а ежечасно. Тут Вы можете заранее предсказать дату окончания "срока годности" сформированных данных.
PHP-программа может управлять кэшированием результатов ее работы формируя дополнительные поля в заголовке HTTP ответа вызовом функции Header().
Несколько общих утверждений характерных не только для PHP-программ:
* Страницы передаваемые по POST никогда не сохраняются в кэш.
* Страницы запрашиваемые по GET и содержащие параметры (в URL присутствует '?') не сохраняются в кэш, если не указано обратное
Таким образом в большинстве ситуаций дополнительных инструкций в программу добавлять не надо. Основные моменты на которые следует обратить внимание можно свести к двум:
* запрет кэширования документов, кэшируемых по умолчанию
* кэширование документов, не подлежащих кэшированию по умолчанию.
Рассмотрим пример - прайс лист обновляемый по понедельникам. Вы заранее знаете, что содержание страницы можно хранить в кэш до наступления новой недели, что и следует указать в заголовке ответа обеспечивая нужное поведение страницы в кэш. Основная задача - получить дату следующего понедельника в формате RFC-1123.
.
.
.
.
.
Этим методом можно эффективно управлять поведением страницы в кэш и пременим но для большого числа страниц - так или иначе можно выделить временные интервалы в течении которых содержание страницы остается постоянным. Реальное положение вещей таково, что страницы большинства динамических сайтов имеют определенное время жизни исходя из которго разработчик может сераер более приятным для работы.
Другой подход, применяемый при более оперативном обновлении информации и одновременной высокой посещаемости сервера (иначе кэширование не будет эффективным) состоит в использовании заголовка Cache-control: max-age=секунды, определяющий время по истечении которого документ считается устаревшим и имеющий больший приоритет при вычислении "свежести" документа. Если Вы публикуете новости с интервалом в 30 минут:
Еще более интеллектуальный вид управления предоставляет HTTP/1.1 на основе содержимого с помощью директив Vary. Я очень рекомендую применять его при формировании изображений или текстов большого объема, которые как показывает практика изменяются крайне редко.
При этом у пользователя в случае возврата не будет происходить их повторной выгрузки, если содержание осталось прежним, и страница будет взята с Вашего сервера, если ее содержание изменилось. Рассмотрим пример выдачи изображения из базы данных индентифицируемых по ID. Вызов страницы выглядит следующим образом:
а значит по правилам страница не будет сохраняться в кэш (присутствуют параметры), но через заголовок можно управлять этим.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Для управления используется MD5 сумма содержимого изображения. Пока содержание не изменилось, сумма будет постояной. В случае изменения содержания в базе на сервере клиент выполнит запрос для повторного формирования содержания. Пока изображение постоянно содержимое будет отображаться из кэш.
Все, что мы записываем в переменную $s (массив), будет доступно для чтения при следующем заходе посетителя на сервер. Про сессии, на самом деле, можно сказать очень много, чтобы описать возможности и особенноти.. Но если вы поюзаете пример и попробуете использовать в своих задачах, сами поймете.
Интересно, есть ли технология преобразования Wave-формата в обычный набор звуковых данных? К примеру, мне необходимо удалить заголовок и механизм (метод) сжатия, которые могут компилироваться и сохраняться вместе с Wave-файлами.