Вход на хостинг
IT-новости
20.04.2016 iPhone 2017 года поместят в водонепроницаемый корпус из стекла
Линейка iPhone в новом году серьезно поменяется. В этом уверен аналитический исследователь Мин Чи Ку......
30.07.2015 Ищем уникальный контент для сайта
Ищем уникальный контент для сайта Без уникального контента Ваш сайт обречен на то, что его страницы......
11.05.2015 Распространённые ошибки разработчиков сайтов
Не секрет, что в сети Интернет насчитывается миллионы сайтов, и каждый день появляются тысячси новых......
Аккуратная настройка SSI
Алексей Мичурин
Документация и описания SSI столь же многочисленны, сколь широко применение этого механизма. И тем удивительнее то, как мало внимания уделяется оптимизации SSI и при написании документации, и при использовании SSI на практике.
С егодня мы обсудим три аспекта настройки механизма SSI. Во-первых, SSI часто используется для включения внешних файлов в состав SHTML-документа. Эти включаемые файлы, естественно, не являются полноценными, законченными HTML-документами и не предназначены для просмотра посетителями. Как запретить доступ к этим файлам? Во-вторых, включаемые файлы могут быть статическими, а могут, в свою очередь, содержать SSI-инструкции. Как регламентировать обработку этих файлов, запретив SSI-интерпретатору обрабатывать заведомо статические документы? И в-третьих, как настроить механизм кэширования SHTML-документов? Известно, что по умолчанию SHTML-документы не кэшируются, но зачастую они не так уж динамичны, чтобы полностью отказаться от кэширования.
Все поставленные задачи мы будем решать средствами сервера Apache, ориентируясь на версию 1.3, которая не торопится сдавать свои позиции. Однако все предлагаемые рецепты будут работать и на Apache 2.0. На существенных отличиях между «старым» и «новым» Apache мы будем останавливаться особо.
Сервер Apache, как известно, работает на множестве платформ. Большинство рецептов, приведённых в этой статье, столь же универсальны. Исключения будут отмечены.
Регламентируем доcтуп
Судя по названию (Server-Side Includes), основным предназначением SSI является включение файлов. Неудивительно, что наиболее часто разработчики используют SSI-директиву include.
Например, можно разместить код шапки страницы, общий для всех страниц, в отдельном файле:
<!-- файл шапки head.shtml -->
<html>
<head>
<title>Название</title>
</head>
<body>
<h1>Название</h1>
<hr>
А потом подключать содержимое этого файла ко всем документам:
<!--#include virtual="head.sthml" -->
<p>Содержимое страницы</p>
</body>
</html>
Это действительно значительно упрощает и разработку, и особенно поддержку. Ведь чтобы изменить дизайн заголовка на всех страницах, теперь достаточно отредактировать всего один файл.
Но возникает вопрос: как запретить пользователю просматривать SSI-«кирпичики», такие как head.ssi, отдельно от результирующего документа? Обычно, когда необходимо надёжно скрыть какие-то файлы от посетителя, их просто размещают за пределами части файловой системы, доступной для сервера. Это идеальное решение, но оно не применимо для нашей задачи, так как SSI позволяет включать только файлы, потенциально доступные посетителю. Иначе SSI представлял бы немалую угрозу безопасности.
ООО Дельта-Технология ©2007 - 2023 год
Нижний Новгород, ул. Дальняя, 17А.
