Перестал работать dav.

Возвращает 405 Method Not Allowed в директории, где явно прописано DAV on.

Как выяснилось, в Apache 2.4 кто-то додумался, что DAV (в смысле методы PROPFIND, OPTIONS и иже с ними) должны быть разрешены только там, где DirectoryIndex disabled.

Я даже понимаю, какая извращенная security-логика за этим стояла. Ну примерно такая же как за стриптизом в аэропортах.

Но вот раньше можно было DAV-клиентом редактировать сайт по тому же URL по которому его смотреть в браузере. При этом в браузере ты видел сайт, а в DAV-клиенте - список файлов (он их методом PROPFIND смотрит, а не GET).

Теперь почему-то разработчики Apache настаивают что по той URL, по которой можно использовать DAV-клиент, браузер тоже должен видеть пачку файлов.

Раньше соответствующий кусок конфига апача выглядел как

DocumentRoot /srv/www
<Directory /srv/www>
  Dav On
  AuthType Basic
  AuthName DAV
  AuthUserFile /etc/apache2/dav.passwd
  <LimitExcept GET OPTIONS>
           require valid-user
  </LimitExcept>
</Directory>

Теперь приходится делать вот так:

DocumentRoot /srv/www
Alias /dav /srv/www
<Directory /srv/www>
Require all granted
</Directory>

<Location /dav>
   DirectoryIndex disabled
   Dav On
     AuthType Basic
  AuthName DAV
  AuthUserFile /etc/apache2/dav.passwd
  Require valid-user
</Location>

И, соответственно, браузер натравливаем на https://my.server.domain, а кадавра - на
https://my.server.domain/dav

Хотя казалось бы разделение на URL для редактирования и URL для просмотра имело смысл тогда, когда статические сайты смотрели по http, а не в эпоху всеобщего https.

Теперь вопрос - а какой юз-кейс остался для директивы LimitExcept?

This entry was originally posted at http://vitus-wagner.dreamwidth.org/1172790.html. Please comment there using OpenID. Now there are comments

Народ, а кто может подсказать фреймворки для построения веб-страниц, в которых порядок генерации отдельных фрагментов не принципиален?

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

Ну то есть что-то подобное есть в питоновских вариантах на базе Twisted и Tornado, но у twisted просто ужасный синтаксис в этом месте. Опять же Twisted и Tornado не самые популярные инструменты у веб-разработчков.

Дело в том, что выяснилось, что если не соблюдать четкую последовательность запрос-ответ-запрос-ответ, а вывалить в бэкенд сразу сотню запросов, а потом читать ответы, у постгреса даже на той же машине, получается ускорение примерно вдвое (на простых запросах, сводящихся к одному index range scan или index lookup).

Соответственно, хочется попытаться оторвать от libpq существующую там проверку на "если результат предыдущего запроса не прочитан, со следующим посылаем", и попытаться это применить на каких-то реальных задачах.

Подобные паттерны с сотнями легких запросов в рамках одного коннекта характерны как раз для динамических веб-фреймворков.

У меня возникло подозрение, что подобный стиль работы естественным образом вписывается во всякие решения на базе haskell или ocaml. Но я web-фреймворков на базе этих языков (да и самих-то языков) толком не знаю.

This entry was originally posted at http://vitus-wagner.dreamwidth.org/1132043.html. Please comment there using OpenID. Now there are comments

А не подскажет ли кто правильное облачное хранилище данных?

Требования такие

1. Чтобы много и дешево. Не менее чем 100Гб и цена заметно меньше чем у дешевых виртуалок (каковые по-моему уже до $5/мес упали).
2. Чтобы никаких специальных клиентов - чтобы заливать туда файлы можно было по стандарным протоколам - webdav, ftp, smb, rsync (достаточно любого одного из)
3. Чтобы файлы оттуда можно было раздать по http всему свету, но не как в яндексе, а чтобы если там лежит index.html, то введя ссылку на него в браузер, можно было бы увидеть этот html так, как автор его задумал, и все относительные ссылки бы работали. (собственнно, ровно этим меня не устраивае яндекс - он пытается как-то сам делать thumbnail-ы моих фотографий а html-и предлагает скачать вместо того, чтобы в браузере показывать.

This entry was originally posted at http://vitus-wagner.dreamwidth.org/1116485.html. Please comment there using OpenID. Now there are comments

Вот представьте себе, что есть сайт. Файлы на этот сайт выкладываются с помощью rsync, причем не с -e ssh, а с двумя двоеточиями после hostname. Кто не понял, зачем там два двоеточия, прекращает читать этот пост, читает man rsync, и возвращается сюда просветленный.

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

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

Данные, выкладываемые на сайт, тоже вроде ничего сенситивного не содержат - файлы паролей для Basic Auth там внутри дерева не лежат, опция ExecCGI на всём, доступном для записи по rsync выключена, php и подобных тоже нету.

This entry was originally posted at http://vitus-wagner.dreamwidth.org/1102139.html. Please comment there using OpenID. Now there are comments

Новость хорошая:

Давно собирался пофиксить свой фотоархив чтобы все дни начиная с глубокого XX века не были свалены в один длинный листинг. Ну вот, наконец, собрался.

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

И держать mod_rewrite на сервере не хочется. Не настолько, насколько mod_php, но всё же.

Так что я решил задачу превращения урл вида /photo/2015.06.04-ploskoe в /photo/2015/06.04-ploskoe средствами mod_alias. Конкретнее, директивой RedirectMatch.

Новость плохая:

Выяснилось, что файл паролей к бардовскому архиву у меня лежал в таком месте гигнувшегося диска, которое не бэкапилось. Сам архив - бэкапился, а пароли к нему - того. Так что если я кому давал туда доступ, и этот кто-то не выкачал сразу всё, может попросить у меня еще раз, сгенерю новый пароль.

This entry was originally posted at http://vitus-wagner.dreamwidth.org/1097440.html. Please comment there using OpenID. Now there are comments