Нагуглил следующее:
Предлагают юзать $uri вместо $request_uri как ключ кеша, но у меня пока не работает (гуглю).
Простой вариант, даже не требующий отдельного location для ssi, это включать SSI с GET параметром, указывающим на уровень его вложенности (level=N) и добавить $query_string в ключ кеша.
Читаю дальше, спасибо за наводку, в любом случае
Да, так работает, но проблема опять появляется когда использую многоуровневые ssi вложения: т.е. включаю ssi внутри ssi.
Что можно сделать в этом случае? Плодить locations? Становится неудобно следить за тем, как именно надо подключать ssi в конкретном месте, чтоб он попал в другой location.
V2NEK, Всмысле?
У меня все запросы к бекенду..
И мне надо кешировать и саму страницу и ее инклуды, на разное время
+1
10 символов
Маршрутизация через несколько каналов/провайдеров.
4.2.1. Раздельный доступ - ваш случай
Пользовательские ключи лежат в ~/.ssh/authorized_keys. Его можно удалить.
В /etc/ssh/sshd_config можно указать, какие пользователи имеют право конектиться и с каких хостов. Пример:
user1 может конектиться по ssh с любого IP. root - только с 11.11.11.0/24, все остальные не могут.
(sudo) rm -rf /path
что пишет? посмотрите в dmesg тоже
Если нужно чтоб правило не применялось, не пишите его. Это самый надежный способ.
Не понятно чего вы хочете..
Что такое rhost? Обратная DNS запись? Она никакого отношения к апачу и его rewriteRules не имеет.
Показывайте правила.
Что вы имеете ввиду?
Не обязательно commit, можно по tag обращаться или еще как-то. К тому же на dev сервере будет только master ветка, практически готовая к продакшену
