Я держу на сервере некоторые служебные/вспомогательные файлы, используемые в Server-Side Includes (SSI), и хочу запретить Apache отдавать их наружу по запросам.

В общем случае запрет отдачи файлов рекомендуется делать через Files/FilesMatch и Allow/Deny, но Allow/Deny работают для любых файлов, запрашиваемых при обработке запроса. Если я запрещаю эти файлы через Deny, они перестают быть доступны и самому серверу при обработке SSI.

Другой часто рекомендуемый способ — через RewriteRule, но тогда соответствующие правила придется включать в .htaccess каждого каталога, а это чертовски неудобно.

Что еще можно придумать без извращений, чтоб файлы были доступны самому апачу для SSI, но недоступны для получения по прямому запросу?

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ> Что еще можно придумать без извращений, чтоб файлы были доступны самому апачу для SSI, но недоступны для получения по прямому запросу?

Поставить nginx перед apache и запретить на нем.

Здравствуйте, Anton Batenev, Вы писали:

AB>Поставить nginx перед apache и запретить на нем.

Я ж не зря указал, что это нужно сделать именно в Apache и через .htaccess. Подсказка: сервер контролирую не я.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ> Другой часто рекомендуемый способ — через RewriteRule, но тогда соответствующие правила придется включать в .htaccess каждого каталога, а это чертовски неудобно.

Укажи RewriteBase на нужный каталог и правила будут действовать на все дочерние тоже.

Здравствуйте, rudzuk, Вы писали:

R>Укажи RewriteBase на нужный каталог

Который из них "нужный", если я хочу, чтоб это действовало на все каталоги?

R>правила будут действовать на все дочерние тоже.

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

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ> R>Укажи RewriteBase на нужный каталог

ЕМ> Который из них "нужный", если я хочу, чтоб это действовало на все каталоги?

Значит укажи корень: RewriteBase /

ЕМ> R>правила будут действовать на все дочерние тоже.

ЕМ> Каким образом? По умолчанию правила не наследуются, и действуют только те, что указаны в .htaccess конкретного каталога.

Наследуются. Далее (в дочерних каталогах) можно перекрыть правила вложенным .htaccess

Здравствуйте, rudzuk, Вы писали:

R>Значит укажи корень: RewriteBase /

Я, честно говоря, вообще не понимаю, при чем тут RewriteBase. Судя по описанию, оно задает базу для второго параметра RewriteRule, а на кой в решаемой задаче нужен изменяемый второй параметр?

R>Наследуются. Далее (в дочерних каталогах) можно перекрыть правила вложенным .htaccess

Для всего, кроме RewriteCond/RewriteRule. А если наследовать и их, то придется попрощаться с per-directory rules, я тогда вообще вздернусь.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ> Я, честно говоря, вообще не понимаю, при чем тут RewriteBase. Судя по описанию, оно задает базу для второго параметра RewriteRule, а на кой в решаемой задаче нужен изменяемый второй параметр?

Это я чего-то протупил. За давностью лет уже забыл нафиг включил ее в файл.

ЕМ> Для всего, кроме RewriteCond/RewriteRule.

Все наследуется. У меня так сделана блокировка файлов по имени начинающегося с точки и некоторые модификации урлов (прописывать такое в каждом каталоге... дурнее не придумаешь).

ЕМ> А если наследовать и их, то придется попрощаться с per-directory rules, я тогда вообще вздернусь.

.htaccess и сделан для per-directory

Здравствуйте, rudzuk, Вы писали:

R>У меня так сделана блокировка файлов по имени начинающегося с точки и некоторые модификации урлов (прописывать такое в каждом каталоге... дурнее не придумаешь).

Хм, как именно у Вас это сделано? Судя по описанию mod_rewrite, до него доходит дело только после того, как URL отображен на файловую систему — то есть, найден путь в ФС, соответствующий наиболее длинному пути в URL. Я отлаживаю локальную копию сайта в локальном сервере Apache 2.4.38, и по логам вижу, что он не просматривает все .htaccess, начиная от корня, как это делает core, а сразу берет .htaccess из последнего существующего каталога.

Если включить наследование, то он тупо добавляет все родительские правила до/после правил из этого файла, в том же виде, в каком они указаны в родительских каталогах. А там они, как правило, указываются для конкретного контекста в URL. Делать в каждом каталоге правила, работающие в любом другом — еще дурнее.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ> R>У меня так сделана блокировка файлов по имени начинающегося с точки и некоторые модификации урлов (прописывать такое в каждом каталоге... дурнее не придумаешь).

ЕМ> Хм, как именно у Вас это сделано?

Конкретно запрет на имена начинающиеся с точкаи выглядит так:

RewriteEngine On
RewriteBase /

# block any object with leading dot
RewriteCond %{REQUEST_URI} (.*)/\.(.*)
RewriteRule (.*) $1 [R=404,L]

Этот .htaccess лежит в корне сайта и его правила действуют на все подкаталоги. В паре дочерних каталогов есть собственные .htaccess со своими правилами не относящимися к mod_rewrite.

Здравствуйте, rudzuk, Вы писали:

R>Этот .htaccess лежит в корне сайта и его правила действуют на все подкаталоги.

Он не должен действовать на подкаталоги, если не разрешено наследование правил (RewriteOptions Inherit*). У Вас оно включено? Если нет, то какая версия Apache, и Apache ли это?

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ> R>Этот .htaccess лежит в корне сайта и его правила действуют на все подкаталоги.

ЕМ> Он не должен действовать на подкаталоги, если не разрешено наследование правил (RewriteOptions Inherit*). У Вас оно включено? Если нет, то какая версия Apache, и Apache ли это?

$apache2 -v
Server version: Apache/2.4.52 (Ubuntu)
Server built:   2023-05-03T20:02:51

RewriteOptions вообще нигде не указано. Ни в конфиге модуля mod_rewrite, ни в конфиге сайта, ни в .htaccess.

Здравствуйте, rudzuk, Вы писали:

R>RewriteOptions вообще нигде не указано.

Вы твердо уверены, что Ваши правила действительно работают? Попробуйте, например, сменить 404 на 403 — в результатах запроса ошибка изменится для любых файлов, начинающихся с точки, в любых дочерних каталогах?

Если да, то как это согласуется с описанием технологии работы mod_rewrite? Он не должен так работать.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ> Вы твердо уверены, что Ваши правила действительно работают? Попробуйте, например, сменить 404 на 403 — в результатах запроса ошибка изменится для любых файлов, начинающихся с точки, в любых дочерних каталогах?

Проверил. Работает. Сменил на 403 — отдается страница с 403. Закоментировал это правило — стали отдаваться файлы с лидирующей точкой в имени. Проверял в каталогах разной глубины. Конфиг (.htaccess) лежит в корне.

ЕМ> Если да, то как это согласуется с описанием технологии работы mod_rewrite? Он не должен так работать.

Можно цитату, где говорится, что не должен?

Здравствуйте, rudzuk, Вы писали:

R>Проверил. Работает. Сменил на 403 — отдается страница с 403. Закоментировал это правило — стали отдаваться файлы с лидирующей точкой в имени. Проверял в каталогах разной глубины. Конфиг (.htaccess) лежит в корне.

Крайне странно. Я такого не мог добиться никогда, и сейчас тоже — вставил Ваш код, как есть, в корневой .htaccess, и он действует только на корень.

R>Можно цитату, где говорится, что не должен?

Раздел "API Phases":

First, it uses the URL-to-filename translation hook, which occurs after the HTTP request has been read, but before any authorization starts. Secondly, it uses the Fixup hook, which is after the authorization phases, and after per-directory configuration files (.htaccess files) have been read, but before the content handler is called.
...
In per-directory context (i.e., within .htaccess files and Directory blocks), these rules are being applied after a URL has already been translated to a filename.

Поскольку mod_rewrite — это модуль расширения, он может вызываться только через определенные API Hooks, а не в любой момент, когда пожелает. Судя по описанию, такой API Hook первый раз вызывается после того, как будет найдено отображение URL на путь ФС. О том, чтобы mod_rewrite вызывался каждый раз, когда в ФС найден очередной каталог, соответствующий пути URL, я никогда не слышал.

Соответственно, глядя в логи, я вижу там то же самое: обработка запроса в mod_rewrite начинается с применения правил из .htaccess в последнем подходящем каталоге, и им же и завершается. Применить правила из родительских каталогов он может только в порядке наследования, если оно разрешено.

У Вас точно не разрешено наследование правил? Какой порядок обработки запроса отражается в логах?

Здравствуйте, rudzuk, Вы писали:

R>Конкретно запрет на имена начинающиеся с точкаи выглядит так:

Поставил 2.4.58 рядом с 2.4.38, еще раз вставил в корневой .htaccess Ваш код — работает точно так же.

Еще одно уточнение: когда Вы проверяли его работу, то вводили имена существующих файлов, начинавшихся с точки? Или, хотя бы, несуществующих файлов, но в существующих каталогах? Иначе, если первый же за корневым каталог в URL не существует, то закономерно будет применен корневой .htaccess.

И, надеюсь, проверяли не на именах вида .ht*?

Вообще, такие правила нужно проверять очень аккуратно. Я уже не раз налетал на то, что, не посмотрев в логи, можно спутать 404, возвращаемый сервером для несуществующего файла, с 404, который должно возвращать правило реализации запрета, а 403, который должно возвращать правило для .htaccess — с 403, который Apache возвращает для них по умолчанию (с какой-то версии в httpd.conf появилось Require all denied для ".ht*").

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ> R>Проверил. Работает. Сменил на 403 — отдается страница с 403. Закоментировал это правило — стали отдаваться файлы с лидирующей точкой в имени. Проверял в каталогах разной глубины. Конфиг (.htaccess) лежит в корне.

ЕМ> Крайне странно. Я такого не мог добиться никогда, и сейчас тоже — вставил Ваш код, как есть, в корневой .htaccess, и он действует только на корень.

В общем, почитал я доку про наследование в mod_rewrite. Там речь идет о наследовании для дочерних .htaccess со своими правилами перезаписи. Проверил у себя и это действительно так. Если в дочернем каталоге есть свой .htaccess с собственными правилами перезаписи, то родительские правила не применяются.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ> Еще одно уточнение: когда Вы проверяли его работу, то вводили имена существующих файлов, начинавшихся с точки? Или, хотя бы, несуществующих файлов, но в существующих каталогах? Иначе, если первый же за корневым каталог в URL не существует, то закономерно будет применен корневой .htaccess.

ЕМ> И, надеюсь, проверяли не на именах вида .ht*?

ЕМ> Вообще, такие правила нужно проверять очень аккуратно. Я уже не раз налетал на то, что, не посмотрев в логи, можно спутать 404, возвращаемый сервером для несуществующего файла, с 404, который должно возвращать правило реализации запрета, а 403, который должно возвращать правило для .htaccess — с 403, который Apache возвращает для них по умолчанию (с какой-то версии в httpd.conf появилось Require all denied для ".ht*").

Да, проверял на существующих файлах. Да, проверял аккуратно. Да, не на .htaccess.

Здравствуйте, rudzuk, Вы писали:

R>Если в дочернем каталоге есть свой .htaccess с собственными правилами перезаписи, то родительские правила не применяются.

Я даже предположить не мог, что у Вас правила перезаписи есть только в корневом .htaccess. У меня они где-то есть, где-то нет, поэтому, за невозможностью управлять этим глобально, остается только вставлять одинаковые правила в каждый .htaccess, что по определению идиотизм.

Каждый раз, когда правлю конфигурацию сервера, задаюсь вопросом: что курили разработчики Apache, чтоб наплодить, с одной стороны, так монументально, а с другой — так бестолково. Ведь самые элементарные приемы (возможность определять переменные в .htaccess, возможность включать в .htaccess другие файлы, возможность для mod_rewrite просматривать .htaccess по мере продвижения по пути, и т.п.) позволили бы радикально упростить управление.

Возможно, эти ребята просто давно забыли, что уних — по определению многопользовательская система, и у администратора конкретного сервера может не быть доступа к корневым конфигам.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ> R>Если в дочернем каталоге есть свой .htaccess с собственными правилами перезаписи, то родительские правила не применяются.

ЕМ> Я даже предположить не мог, что у Вас правила перезаписи есть только в корневом .htaccess.

Я об этом почти сразу написал

Автор: rudzuk
Дата: 05.11.23

:

В паре дочерних каталогов есть собственные .htaccess со своими правилами не относящимися к mod_rewrite.

ЕМ> Каждый раз, когда правлю конфигурацию сервера, задаюсь вопросом: что курили разработчики Apache, чтоб наплодить, с одной стороны, так монументально, а с другой — так бестолково. Ведь самые элементарные приемы (возможность определять переменные в .htaccess, возможность включать в .htaccess другие файлы, возможность для mod_rewrite просматривать .htaccess по мере продвижения по пути, и т.п.) позволили бы радикально упростить управление.

ЕМ> Возможно, эти ребята просто давно забыли, что уних — по определению многопользовательская система, и у администратора конкретного сервера может не быть доступа к корневым конфигам.

Я тоже прифигел от конфигурирования апача

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Что еще можно придумать без извращений, чтоб файлы были доступны самому апачу для SSI, но недоступны для получения по прямому запросу?

Бросай курить вставай на лыжи (ну, метафорически) В лес этот SSI, попробуй Astro (статический генератор) — оно рулит. SSI в него должен конвертироваться на раз-два.

Здравствуйте, bnk, Вы писали:

bnk>попробуй Astro (статический генератор) — оно рулит.

Вот только открыл сайт, и сразу поперло отторжение. Заглавная страница сделана откровенно претенциозно, в стиле "как вы до сих пор жили без нашего чудо-продукта?". Ни слова о том, какое место занимает чудо-продукт в экосистеме. Такое делается главным образом для дебилов примитивных виндузятников и макосников. Однако, в Get Started приведены командные строки для терминала — они для кого? Если для технаря-админа, то для кого заглавная страница? Если для тупого юзера, то что он будет с ними делать?

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

Оно только для тех, у кого собственный сервер? Или я могу поставить это чудо на shared?

bnk>SSI в него должен конвертироваться на раз-два.

Да мне б и SSI хватило за глаза, если б его нечеловеческие технологии. Стандартное оформление через <!-- и --> невозможно использовать внутри тэгов — HTML-редакторы обижаются, и исправляют этот ужас, как могут. А SSIStartTag/SSIEndTag доступны только в глобальной конфигурации, в .htaccess они не поддерживаются. Чем думали люди из команды Apache, когда все это городили — не представляю.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Вот только открыл сайт, и сразу поперло отторжение. Заглавная страница сделана откровенно претенциозно, в стиле "как вы до сих пор жили без нашего чудо-продукта?". Ни слова о том, какое место занимает чудо-продукт в экосистеме. Такое делается главным образом для дебилов примитивных виндузятников и макосников. Однако, в Get Started приведены командные строки для терминала — они для кого? Если для технаря-админа, то для кого заглавная страница? Если для тупого юзера, то что он будет с ними делать?
ЕМ>Полазив по сайту, так и не понял, куда там лошадь запрягать в каких ОС его можно использовать, и как именно это сделать, кроме как ввести волшебную команду.
ЕМ>Оно только для тех, у кого собственный сервер? Или я могу поставить это чудо на shared?

Ну вот вечно ты так, требуешь к себе человеческого отношения

Это генератор статического сайта. Можно хостить где угодно, хоть на гитхабе забесплатно.
Если будет время попробую написать как это использовать, типа руководства для динозавров, настолько проникся

bnk>>SSI в него должен конвертироваться на раз-два.

ЕМ>Да мне б и SSI хватило за глаза, если б его нечеловеческие технологии. Стандартное оформление через <!-- и --> невозможно использовать внутри тэгов — HTML-редакторы обижаются, и исправляют этот ужас, как могут. А SSIStartTag/SSIEndTag доступны только в глобальной конфигурации, в .htaccess они не поддерживаются. Чем думали люди из команды Apache, когда все это городили — не представляю.

Ну да, про что и речь. В astro делается блоками (island)

header.html

HEADER

footer.html

FOOTER

content.md (markdown для примера, оно import много чего умеет)

**MARKDOWN** content

index.astro (конвертируется в index.html)

---
import Header from "./header.html";
import Footer from "./footer.html";
import Content from "./content.md";
---

<!doctype html>
<html lang="en">
  <head>
    <title>My page</title>
  </head>
  <body>

    <Header />

    <h1>HELLO WORLD</h1>

    <Content />

    <Footer />

  </body>
</html>

Здравствуйте, bnk, Вы писали:

bnk>Ну вот вечно ты так, требуешь к себе человеческого отношения

— Как называется мужчина, который может, но не хочет?
— Сволочь он! Сволочь!

bnk>Можно хостить где угодно

"Где угодно" — это включая калькуляторы и смарт-часы? Под виндой работать может?

И он должен работать там же, где будет лежать сайт, или может просто создавать дерево каталогов, которое затем можно закачать на сервер?

bnk>Если будет время попробую написать как это использовать, типа руководства для динозавров

А что ж сами разработчики не напишут?

bnk>index.astro (конвертируется в index.html)

А брать исходники в HTML, и подставлять туда значения, определенные в конфигурации, оно умеет? Писать все в MarkDown как-то не хочется.

Здравствуйте, Евгений Музыченко, Вы писали:

bnk>>Можно хостить где угодно

ЕМ>"Где угодно" — это включая калькуляторы и смарт-часы? Под виндой работать может?
ЕМ>И он должен работать там же, где будет лежать сайт, или может просто создавать дерево каталогов, которое затем можно закачать на сервер?

Конечно. Там по сути нечему "работать", на выходе получаешь просто каталог "dist" с HTML файлами, который надо закачать на сервер. Это же и есть суть статической генерации.
Ну опционально еще кроме html там может быть javascript, если он где-то используется. Ну и файлы которые ты сам туда положил (любого типа)

ЕМ>А брать исходники в HTML, и подставлять туда значения, определенные в конфигурации, оно умеет?

Да, умеет. Самое простое это расширение .html изменить на .asto чтобы файл обрабатывался
Например если из переменной окружения, то примерно так как ниже.
Можно и свой код влепить любой в принципе, который будет выполняться во время компиляции сайта (ну, чтобы получить эту "конфигурацию", если это что-то специфическое)
Код в HTML не включится (все что между "----" обрабатывается во время компиляции)

---
const myValue = import.meta.env.MY_ENV_VARIABLE;
---
<html>
  <body>{myValue}</body>
</html>

Да, для редактирования (ну чтобы автокомплит был и прочие приятности) я VS Code использую, там есть специализированное расширение.
А вообще есть даже целая CMS, внутри VS Code (но я ее не использую, может в будущем)

И все что выше, это даже близко не основная фишка
Основная для меня — что можно так же как html или md/mdx файлы выше импортировать КОМПОНЕНТЫ (написанные на React, Angular, Vue, etc)

Здравствуйте, bnk, Вы писали:

bnk>Там по сути нечему "работать", на выходе получаешь просто каталог "dist" с HTML файлами, который надо закачать на сервер.

То есть, по сути, это макропроцессор?

А зависимости оно отслеживает? Если в исходниках изменился, скажем, один прототип страницы, или параметры, затрагивающие только часть страниц, он пересоздает только их, или все скопом? Это я к тому, какой объем нужно будет загружать на сервер после каждой модификации.

Ну и под виндой (без WSL) его запустить можно?

bnk>можно так же как html или md/mdx файлы выше импортировать КОМПОНЕНТЫ (написанные на React, Angular, Vue, etc)

Мне это пока не актуально.

Здравствуйте, Евгений Музыченко, Вы писали:

bnk>>Там по сути нечему "работать", на выходе получаешь просто каталог "dist" с HTML файлами, который надо закачать на сервер.

ЕМ>То есть, по сути, это макропроцессор?

Да, можно и так обозвать

ЕМ>А зависимости оно отслеживает? Если в исходниках изменился, скажем, один прототип страницы, или параметры, затрагивающие только часть страниц, он пересоздает только их, или все скопом? Это я к тому, какой объем нужно будет загружать на сервер после каждой модификации.

Все скопом. Т.е. есть явный шаг "компиляция" на котором собственно собирается сайт. Как обычная софтина компилируется.
Чтобы меньше заливать, можно деплоить из GIT репозитория например (но вообще-то откуда там большие объемы, там же HTML файлы — килобайты, не мегабайты?)

ЕМ>Ну и под виндой (без WSL) его запустить можно?

Конечно. Просто открываешь папку в VS Code и вперед. Но командная строка все же нужна (чтобы запустить компиляцию, например).
Ну или чтобы предпросмотр сделать без деплоймента на сервер (локально оно имеет встроенный веб-сервер для предварительного просмотра)
npm run dev / npm run build / npm run preview

Да, NodeJS понятно должна быть (чтобы "npm" работало)

ЕМ>Мне это пока не актуально.

Ну там и другие фишки есть. Например "макрос с параметрами".
Можно сделать повторно используемый блок, и вызывать его с разными параметрами (ну карточка продукта например)

product-card

---
const { name, description } = Astro.props
---
<div class="my-product-card">
   <div>{name}</div>
   <div>{description}</div>
</div>

index

---
import ProductCard from 'product-card'
---
<div>
   <ProductCard name="App 1" description="..." />
   <ProductCard name="App 2" description="..." />
</div>

Да, язык везде javascript/typescript.

bnk>В лес этот SSI
+1
Только сделай на php. Зачем такой изврат?

По теме:
Deny from all
Allow from env=MY_VALUE

Я не знаю. Есть там в этом SSI возможность переменные среды устанавливать

Здравствуйте, TailWind, Вы писали:

bnk>>В лес этот SSI

TW>+1
TW>Только сделай на php. Зачем такой изврат?

Для PHP требуется (платный) сервер. И он тормозной. В общем PHP не нужен, это каменный век.

Здравствуйте, bnk, Вы писали:

bnk>Для PHP требуется (платный) сервер.

Э-э-э... Чем не годится тот сервер, на котором лежит сайт?

bnk>И он тормозной.

Насколько, кстати, тормозной, если не увлекаться запросами к БД и сложной обработкой текстов?

bnk>PHP не нужен, это каменный век.

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

Здравствуйте, Евгений Музыченко, Вы писали:

bnk>>Для PHP требуется (платный) сервер.

ЕМ>Э-э-э... Чем не годится тот сервер, на котором лежит сайт?

Фактом своего существования
Для статических сайтов полно платформ, которые могут хостить такой контент забесплатно, на заданном доменном имени, с CDN, те же GitHub Pages, Cloudflare, Azure Static Website.

bnk>>И он тормозной.

ЕМ>Насколько, кстати, тормозной, если не увлекаться запросами к БД и сложной обработкой текстов?

Ну он всяко медленнее чем просто отдача HTML.

bnk>>PHP не нужен, это каменный век.

ЕМ>Я бы не сказал, что полная статическая перегенерация сайта чем-то "современнее" PHP. Это ж как в традиционной программе, вместо выноса литеральных констант в заголовки, и именования их, выносить эти константы в отдельные файлы, и использовать внешние средства для вставки их опять-таки в литеральной форме. Да, может быть удобно, но технически это ужасно.

IMHO это супер-современное решение для фронтенда на данный момент, круче просто ничего нет
Там же не обязательно делать файлами, можно и программными модулями. Т.е. import можно например и на тайпскриптовые модули делать (получая типизированный импорт с автокомплитом и всеми плюсами проверок времени компиляции), а вовсе не куски HTML. Куски HTML я привел как прямую замену SSI.
Одна гидрация практически любых компонентов (т.е. добавление интерактивности только на фронтенде) чего стоит

Здравствуйте, TailWind, Вы писали:

TW>Allow from env=MY_VALUE

Тогда уж было бы проще через <IfDefine>, ибо SSI может и не использоваться в некоторых страницах.

TW>Есть там в этом SSI возможность переменные среды устанавливать

Есть, но только внутри себя (чтоб потом их подставлять).

Все тайные скрипты в отдельный каталог типа "inc"
Туда .htaccess с deny from all

php из таких каталогов спокойно читает инклюды

Раз хочешь на ssi, то главная страница в открытом доступе. Там переменную и взводи
Но это все равно изврат

Я делаю так: в каталог (путь) где должна быть страница кладу файл _html
В корне сайта .htaccess редиректит, если такой файл есть в каталоге на php скрипт, который отображает header, footer сайта и в том месте где должен быть текст страницы вставляет содержимое _html файла (путь передается в качестве параметра при редиректе). В _html файле обычный текст с обычной html разметкой. Картинки можно в тот же каталог положить. Очень удобно

RewriteEngine On

RewriteCond %{REQUEST_FILENAME}/_html -f
RewriteRule ^(([-_\ a-zA-Z0-9]+/)*)$  /inc/php/_html.php?path=$1  [qsa,E=ACCESS_ALLOWED:1]

<Files _html>
  Deny from all 
</Files>

Интересно, а вот эта добавка "E=ACCESS_ALLOWED:1" будет работать с SSI?

Тогда в закрытом "inc" каталоге нужен .htaccess с:

Deny from all
Allow from env=REDIRECT_ACCESS_ALLOWED

Здравствуйте, bnk, Вы писали:

bnk>Для статических сайтов полно платформ, которые могут хостить такой контент забесплатно

Так у меня уже есть разделяемый хостинг, и нет планов отказываться от него ради "забесплатно". Тем более, что все это "забесплатно" имеет тенденцию со временем становиться или платным, или ограниченным, или совать посетителям назойливую рекламу. Я за разумные компромиссы.

bnk>Ну он всяко медленнее чем просто отдача HTML.

Так и SSI медленнее за счет дополнительной обработки. Вопрос в том, насколько медленнее. Если это единицы процентов на фоне обычных сетевых задержек, и десятки миллисекунд в общем, то нет смысла стремиться это ускорить.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Вопрос в том, насколько медленнее. Если это единицы процентов на фоне обычных сетевых задержек, и десятки миллисекунд в общем, то нет смысла стремиться это ускорить.
Для статики тебе будет неразличимо, имхо. Переименовываешь все html в php и используешь <?php include "" ?> где нужно, например.
В принципе, можно не переименовывать, а настроить апач на процессинг html через php.

Здравствуйте, pva, Вы писали:

pva>Для статики тебе будет неразличимо, имхо.

Я тоже так думаю.

pva>используешь <?php include "" ?>

С ними та же проблема, что и с SSI — HTML-редакторы возбуждаются на тэг внутри тэга (тот же URL). В идеале подошло бы что-то вроде ${var}, но искаропки никто не поддерживает.

Здравствуйте, TailWind, Вы писали:

TW>Все тайные скрипты

У меня не тайные, они просто служебные. Даже если кто-то и запросит такой файл напрямую, он увидит только пустые строки — SSI там все съест. Запретить хочу просто для порядка.

TW>в отдельный каталог типа "inc"
TW>Туда .htaccess с deny from all
TW>php из таких каталогов спокойно читает инклюды

При такой схеме и SSI читает, если при include использовать file, а не virtual. Но мне удобно включать некоторые файлы из родительских каталогов, делая таким образом наследование, а file такого не допускает.

TW>Раз хочешь на ssi, то главная страница в открытом доступе. Там переменную и взводи

Так <IfDefine> таких переменных не видит. Видит только то, что определено в конфигах, да и то лишь админских. Убогая идеология.

TW>Но это все равно изврат

О чем в сфере HTML можно сказать, что оно не изврат?

TW>Я делаю так: в каталог (путь) где должна быть страница кладу файл _html
TW>В корне сайта .htaccess редиректит, если такой файл есть в каталоге на php скрипт, который отображает header, footer сайта и в том месте где должен быть текст страницы вставляет содержимое _html файла (путь передается в качестве параметра при редиректе). В _html файле обычный текст с обычной html разметкой.

Поддерживать целостность при модификациях структуры не тяжело?

ЕМ>Поддерживать целостность при модификациях структуры не тяжело?

Как раз очень удобно
Может я сумбурно объясняю

У тебя в отдельном "inc" каталоге лежит вся php кухня, которая генерит шапочку сайта
Туда редко залезаешь

И есть каталог для каждой странички с файлом _html с её содержимым
Ещё я делаю файлы _php. Для динамического содержимого, типа форм

Всё редактируется с помощью FTP редактора
Очень удобно

ЕМ>Но мне удобно включать некоторые файлы из родительских каталогов, делая таким образом наследование

Не очень понимаю зачем это нужно?

Единственное что можно включать это шапочку сайта
Но гораздо удобнее делать наоборот
Из шапочки включать содержимое страницы, а не из страницы включать шапочку

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>С ними та же проблема, что и с SSI — HTML-редакторы возбуждаются на тэг внутри тэга (тот же URL). В идеале подошло бы что-то вроде ${var}, но искаропки никто не поддерживает.
Это какие-то странные HTML редакторы. У них нет возможности выставить язык не HTML, а PHP?
Я для пыха использую в основном PhpStorm, но он тебе будет тяжеловесен. Для мелких правок Far Manager, но для нормальной подсветки надо чтоб расширение было php а не html.
Проверил notepad++. В принципе, нормально подсвечивает.

ЕМ>Так <IfDefine> таких переменных не видит. Видит только то, что определено в конфигах, да и то лишь админских. Убогая идеология.

Смотрите ещё раз внимательно
Вот этот редирект:

RewriteRule ^(([-_\ a-zA-Z0-9]+/)*)$  /inc/php/_html.php?path=$1  [qsa,E=ACCESS_ALLOWED:1]

Выставляет переменную среды REDIRECT_ACCESS_ALLOWED

Которую можно использовать в .htaccess:

Deny from all
Allow from env=REDIRECT_ACCESS_ALLOWED

Здравствуйте, TailWind, Вы писали:

ЕМ>>Но мне удобно включать некоторые файлы из родительских каталогов, делая таким образом наследование

TW>Не очень понимаю зачем это нужно?

Удобно включать общие элементы — заголовок, меню, "подвал", стили и т.п. Также удобно включать файлы, содержащие определения SSI. Каждый такой файл содержит имя своего каталога, имена подкаталогов, и включает такой же файл из родительского, так что у кода есть переменные, позволяющие подставить как локальные имена, так и полный путь от корня. Иначе все это пришлось бы прописывать в каждой ссылке, и менять все эти ссылки при каждом изменении имен, структуры и вложенности.

Если бы Apache не был таким убогим, и позволял получить все это в SSI и .htaccess, такой нужды не было бы.

TW>Но гораздо удобнее делать наоборот
TW>Из шапочки включать содержимое страницы, а не из страницы включать шапочку

Чем удобнее? И тогда в шапку нужно передавать пути к страницам, а их опять же нужно где-то брать, составлять, обеспечивать соответствие.

Здравствуйте, pva, Вы писали:

pva>Это какие-то странные HTML редакторы.

Это WYSIWYG (в основном FrontPage).

pva>У них нет возможности выставить язык не HTML, а PHP?

Даже если бы она была, как она могла бы работать для WYSIWYG?

pva>для нормальной подсветки надо чтоб расширение было php а не html.
pva>Проверил notepad++. В принципе, нормально подсвечивает.

С подсветкой особых проблем нет, но мне не нравится писать исходный текст в виде кода. А редактора, который позволял бы делать в WYSIWYG только фрагменты HTML-кода, не оформляя их в виде полноценных HTML-страниц, я не нашел.

Здравствуйте, TailWind, Вы писали:

ЕМ>>Так <IfDefine> таких переменных не видит. Видит только то, что определено в конфигах, да и то лишь админских.

TW>Смотрите ещё раз внимательно
TW>Вот этот редирект:

Значит, для RewriteRule сделано исключение. Для SSI — нет. А делать искусственный редирект только ради переменной — только сильнее запутать и так не слишком прозрачную логику.

TW>>Но гораздо удобнее делать наоборот
TW>>Из шапочки включать содержимое страницы, а не из страницы включать шапочку

ЕМ>Чем удобнее? И тогда в шапку нужно передавать пути к страницам, а их опять же нужно где-то брать, составлять, обеспечивать соответствие.


Как чем
Так у вас все страницы это нагромождение include'ов. Если что-то изменится придётся переделывать все страницы. Это очень плохая структура
А в моем подходе только голый html текст

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

А в моем подходе вы просто в середине странцы делаете include её текста

Где брать путь я вам пример привел с редиректом. Он так же передаёт все параметры запроса в скрипт. Как если бы его вызвали с ними
Ну дело хозяйское
Я этот подход долго совершенствовал. И так и так пробовал. Так как любитель статических сайтов, когда страницы хранятся не в MySQL, а в файлах на FTP

ЕМ>Значит, для RewriteRule сделано исключение. Для SSI — нет. А делать искусственный редирект только ради переменной — только сильнее запутать и так не слишком прозрачную логику.

Так вы на свой SSI скрипт сделайте редирект. Тут же на важно на чем скрипт написан на php или SSI

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>С подсветкой особых проблем нет, но мне не нравится писать исходный текст в виде кода. А редактора, который позволял бы делать в WYSIWYG только фрагменты HTML-кода, не оформляя их в виде полноценных HTML-страниц, я не нашел.

А markdown (.md, .mdx) не вариант? Вроде бы самый очевидный для написания контента, позволяет HTML вставки при необходимости

Здравствуйте, TailWind, Вы писали:

TW>Так у вас все страницы это нагромождение include'ов.

Так в любом случае получается нагромождение — не в HTML, так в PHP или .htaccess. В отдельно взятой странице include'ов немного — три-пять-семь, вставляются логически отдельные конструкции (тэги, заголовки, меню, новости и т.п.), которые внутри себя могут вставлять что-то свое. То есть, каждая единица не выглядит особо перегруженной.

TW>Если что-то изменится придётся переделывать все страницы.

Что-то переделывать все равно придется. Схема "общая часть включает код конкретной страницы" подразумевает, что страница монолитна, и внутри себя уже никак не делится.

TW>А в моем подходе только голый html текст

Я не хочу закладываться на структуру, где внутри общей части только голый текст. Где-то есть локальная история изменений, включаемая отдельным div'ом, где-то будут отдельные врезки с вариантами бинарников/платформ и т.п.

TW>Когда у вас шапка, футер, короче вся разметка в одном файле, это гораздо удобней, чем когда у вас сначала верх в одном файле, потом низ в другом. И вы делаете сначала include верха, потом ваш текст, потом include низа. Потому что разметку (отступы табличной html разметки) удобно смотреть/редактировать. Не терять/контролировать взаимные открывающиеся / закрывающиеся тэги

В каждом из этих составных блоков тэги парные (ну, кроме html/body, и иногда div). Контролировать глобальную парность нужды нет.

TW>Где брать путь я вам пример привел с редиректом.

Дык, вместо одного извращения используется другое.

Здравствуйте, TailWind, Вы писали:

TW>на свой SSI скрипт сделайте редирект.

SSI — это не скрипт в традиционном смысле, это вроде сишного препроцессора. Само по себе оно не имеет смысла — только в виде включений в отдаваемые сервером тексты.

Здравствуйте, bnk, Вы писали:

bnk>А markdown (.md, .mdx) не вариант?

Я несколько раз порывался на него перейти, но он неудобен без одновременного рендеринга в HTML-страницу, с применением ее родных стилей. Например, когда набираю/правлю текст во FrontPage 2000 (2003 мне уже не понравился), то сразу вижу, как выглядит текст, насколько заметно выделение курсивом, насколько назойливо выглядит выделение жирным, и т.п. А когда пробовал разные редакторы с рендерингом из MD, регулярно вылезали косяки.

Возможно, это потому, что у FrontPage в режиме HTML рендеринг свой, а все остальное использует системные средства IE, который я как-то давно обновил, после чего долго плевался из-за нежелательных изменений в разных частях системы, которые притащило то обновление. С тех пор обновлять зарекся, хотя вижу, что IE (когда его приходится использовать) многие сайты отображает криво.

Может, уже появились удобные MD-редакторы со встроенным рендерингом в HTML, не зависящие от IE?

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Может, уже появились удобные MD-редакторы со встроенным рендерингом в HTML, не зависящие от IE?

А зачем это если есть live preview?
Я просто меняю текст (markdown) в файле (использую vs code) и смотрю как он меняется на "живом" локально запущенном сайте (сайт открыт в браузере на другом мониторе)

То есть npm run dev.
Ты просто сохраняешь (markdown) файл, и сайт тут же обновляется (с сохранением контекста, т.е. открытой страницы и позиции скорллинга)

	примерно так
	ЗЫ. автокомплит — это copilot (помимо заплетающихся с утра пальцев). Оно все же больше пользы приносит чем вреда

Другими словами, это режим "разработка", когда ты редактируешь сайт. Возможно, я ввел тебя в заблуждение говоря про отдельный шаг компиляции.
Полная компиляция происходит в режиме "продакшен", когда сайт полностью компилируется в отдельную папку в оптимизированном виде.

Здравствуйте, bnk, Вы писали:

ЕМ>>Может, уже появились удобные MD-редакторы со встроенным рендерингом в HTML, не зависящие от IE?

bnk>А зачем это если есть live preview?

Для этого нужно каждый раз сохранять "здесь" и перегружать страницу "там". Не очень тяжело, конечно, но раздражает. Такое хорошо для отладки последовательных процессов, зависящих от начальных и промежуточных состояний, а для оформления ничего лучше WYSIWYG не придумали.

bnk>использую vs code

Меня VS Code пока больше удручает, нежели радует. К нему надо что-то чертовски удобное, чтоб перевесить негатив от него самого.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Здравствуйте, bnk, Вы писали:

ЕМ>>>Может, уже появились удобные MD-редакторы со встроенным рендерингом в HTML, не зависящие от IE?

bnk>>А зачем это если есть live preview?

ЕМ>Для этого нужно каждый раз сохранять "здесь" и перегружать страницу "там". Не очень тяжело, конечно, но раздражает. Такое хорошо для отладки последовательных процессов, зависящих от начальных и промежуточных состояний, а для оформления ничего лучше WYSIWYG не придумали.

Достаточно сохранять "здесь". "Там" перегружается автоматически, (включая сохранение контекста, т.е. состояния), уже много лет как. Это называется "hot reload". Есть ещё "live reload", это когда "там" (автоматически) перегружается страница целиком при сохранении "здесь"

bnk>>использую vs code

ЕМ>Меня VS Code пока больше удручает, нежели радует. К нему надо что-то чертовски удобное, чтоб перевесить негатив от него самого.

А что с ним не так?