Последнее обновление: 17 Сентября 2020 г.

Если вдруг стала некорректно работать технология SSI на сайте… что делать?

Технология SSI расшифровывается как Server Side Includes. При помощи этой технологии сервер собирает html-файл из отдельных частей (кусков), имеющих расширения html или txt. И уже после сборки – отдает клиенту, например, браузеру.

Надо отметить, что это – достаточно старая технология. По сути, она практически ничего не делает, помимо сборки файла. Ну, можно при ее помощи, скажем, вставить текущие время/дату… ну, и еще кое-что. На что-то большее она и не приспособлена.

Тогда для чего же она нужна вообще?

В самом деле, ведь практически все современные сайты – динамические. Так не проще ли вместо SSI использовать любой серверный язык, тот же РНР (который очень широко применяется для создания сайтов)? Тем более, что РНР позволяет реализовать практически любую мыслимую динамичность сайта, что недостижимо для SSI.

Кстати, обзор возможностей SSI можно посмотреть здесь.

Да, это верно. Но, все-таки, существуют несколько неоспоримых преимуществ перед РНР или иным серверным языком. Перечислим их.

1. Обработка файла html и выдача его клиенту при помощи SSI происходит быстрее, чем при использовании пресловутого РНР. Дело в том, что интерпретатор SSI встроен в сервер (например, в Apache), а для работы РНР придется каждый раз, при очередном обращении клиента к сайту, запускать еще и интерпретатор РНР. Понятно, что на это затрачиваются какие-то доли секунды и очень немного (около пары десятков мегабайт) оперативной памяти. И это на небольших малопосещаемых сайтах будет незаметно. Однако, если сайт посещают от 10 тысяч человек в сутки, да еще каждый из них откроет десяток страниц – в итоге затраты времени окажутся уже приличными.

Чтобы максимально использовать скоростное преимущество SSI, следует ОТКЛЮЧИТЬ (если на хостинге вдруг это включено по умолчанию) обработку РНР в файлах html. Почему? Потому, что иначе все равно будет запускаться интерпретатор РНР и будут, соответственно, затраты ресурсов сервера.

Кстати, кроме того, это послужит дополнительной защитой от взлома сайта. Ибо при этом, если вдруг при отправке сообщения (комментария) к статьям на сайте по каким-то причинам даст сбой фильтр сообщений, вполне может оказаться так, что некий хакер может встроить в свое сообщение РНР-код. И при очередном открытии этой страницы хакер может получить практически безграничные возможности на сайте. Например, может легко удалить все файлы сайта, скачать секретные файлы и т.п. Если же html-страница не допускает обработку РНР-кода, то он выведется клиенту (например, браузеру) просто в виде безобидного текста. И хакер сможет полюбоваться на (бесполезные) результаты своего труда в сообщениях.

Понятно, что в настоящее время достаточно многие сайты нередко и не используют страницы html; вместо этого весь контент размещается на страницах php. Конечно, речь здесь не о таких сайтах.

2. Виртуальные хостинги без РНР (но с SSI), как правило, имеют меньшую стоимость чем те, что с РНР даже в минимальной комплектации. Почему? Опять-таки, потому, что SSI затрачивает гораздо меньше ресурсов, чем РНР. Ибо она и неспособна на что-то мало-мальски более серьезное, чем просто собрать html-файл (или shtml – это расширение файла для SSI по умолчанию).

Поэтому, чтобы, как говорится, не стрелять из пушек по воробьям, чтобы разумно расходовать ресурсы сервера, в ряде случаев лучше применять именно SSI в противовес другой динамической технологии. Которая будет в любом случае более затратной.

Кому это может быть нужно?

В первую очередь - небольшим динамическим сайтам, содержимое страниц которых не изменяется в результате их открытия и отправке клиентам. Ведь страницы практически любого, даже условно «статического» сайта, как правило, имеют одинаковые части - кусочки. Это, к примеру, шапка (верхняя часть), фоновое изображение, футер, разные меню… , а также - дата, вроемя последнего изменения страницы и т.п. Тем более, что если и потребуются небольшие изменения, то их можно сделать уже на клиенте средствами javascript.

Также SSI может быть нужной и (не удивляйтесь!) большим порталам, для которых важна скорость загрузки страниц, но которые имеют страницы со множеством типовых вставок (кусков). При этом применение SSI вместо другого динамического языка существенно повысит производительность сервера.

В целом, следует сказать, что SSI не является заменой другим динамическим технологиям (РНР и т.д.), но она очень эффективна тогда, когда необходимо добавить на html-страницу небольшие куски статического контента, так как, в отличие от других динамических технологий, не требует от сервера выполнять много дополнительной работы.

Если же некоторые части страницы все же требуется изменить именно на сервере – то технология SSI поможет, как минимум, в том, что запустит соответствующую программу - на том же РНР.

Вот пример:

<!--#include virtual="/cgi-bin/counter.php" -->

Когда интерпретатор SSI сервера Apache доберется до этой строчки в html-файле, он запустит скрипт counter.php, находящийся в каталоге cgi-bin. А это скрипт уже может сделать какую-то работу: например, отправить клиенту (браузеру) соответствующий код html.

Точно также можно запустить какую-нибудь консольную команду операционной системы. Например, в Windows-хостинге можно запросить список содержимого текущего каталога:

<pre>
<!--#exec cmd="dir" -->
</pre>

В Linux вместо dir нужно написать ls.

Конечно, у SSI имеются недостатки, которые являются обратной стороной ее достоинств. В первую очередь, это, еще раз, несовместимость с РНР. Т.е. нельзя в одном и том же html-файле использовать и SSI, и РНР. А если же все-таки НУЖНО, то стоит присмотреться к примеру выше. Это первый вариант.

А второй вариант – это использование AJAX-запросов после того, как страница уже будет отдана сервером клиенту. При этом вначале сервер отсылает некий обобщенный макет страницы, а клиент уже самостоятельно отсылает AJAX-запросы на сервер. Который присылает затем требуемый контент. Кстати, в настоящее время немало сайтов сделаны именно по такой технологии. Когда вначале клиенту отсылается статическая страница (или динамическая, собранная по технологии SSI), которая затем вскоре уточняется контентом, полученным в ответ на запросы. Вместо AJAX можно использовать и другие технологии, например, вебсокеты, COMET, JSONP.

Однако, время не стоит на месте и иной раз программное обеспечение на хостингах обновляют

Причем, зачастую, без особенного разъяснения владельцам сайтов проблем, связанных с таким обновлением. Это может касаться и технологии SSI, если на сервере обновили, к примеру, Apache. А он может обновиться, например, в результате обновления (апгрейда) операционной системы сервера. Скажем, вместо довольно устаревшего Apache 2.2.* может появиться Apache 2.4.

И тогда, скорее всего, SSI (некоторая ее функциональность) начнет работать некорректно. С этим, кстати, мы сталкивались на практике.

И как тогда быть?

Один из выходов – переписать соответствующие комментарии в html-файлах для управления технологией SSI в соответствии с новыми стандартами. Однако, это может быть затруднительным. Тогда выходом может стать использование параметра для обратной совместимости со старой версией Apache. Это – параметр

SSILegacyExprParser on

Это правило следует прописать в файле .htaccess, находящемся в текущем или любом родительском (вышележащем) каталоге. При этом синтаксис выражений для SSI будет совместим с Apache 2.2.* или более ранней версией.

Примечание. В Denwer этот параметр может не работать. Дело в том, он работает в Apache 2.4, а в Denwer, по крайней мере, по состоянию на конец лета 2020 г., установлена версия Apache 2.2. Поэтому придется в файле .htaccess прописать конструкцию вроде

<IfVersion >= 2.4>
  SSILegacyExprParser on
</IfVersion>

Т.е. если версия Apache не ниже, чем 2.4, то тогда (и только тогда) будет использоваться указанный параметр.

Все бы ничего, но для того, чтобы заработала команда IfVersion, потребуется модуль C:\DenwServer\usr\local\apache\modules\mod_version.so (в Windows), где DenwServer – каталог установки Denwer). Например, у автора статьи его не оказалось. При этом, если необходимо работать в Denwer, придется строчку с параметром SSILegacyExprParser on или удалять, или хотя бы закомментировать (вручную).