try_files может принять только один именованный локейшн.

то есть try_files @named1 @named2; нельзя

или я неправильно понял?

Так там у меня try_files @aws =403;

Чтобы переопределить тело ответа если доступ к файлу запрещен - S3 возвращает XML

Я меняю его на обычный Forbidden

В случае, если ни один файл не найден, то делается внутреннее перенаправление на uri, заданный последним параметром.

только один элемент в списке может быть умным (именованный локейшн или изменение кода). функционал =404 не работает с именованным локейшном. вместо этого вы попытались найти файл с именем '@s3'

Что значит ни один файл не найден? У меня в локейшене aws lua блок и там же proxy_pass

о я говорю, оно реально никуда не проксирует. До амазона пинг 200-300мс, этого не видно во времени ответа

try_files a b c d e f LAST; проверит существование файлов a, b, c, d, e и f, а если ни один из них не найден - то передаст обработку в LAST

в вашем случае @s3 читается не как именованный локейшн, а как имя файла.

вы щас такие крутые штуки обсуждаете. а есть чо почитать

книжко какое ?

http://nginx.org/ru/docs/http/ngx_http_core_module.html

нее

дока нужна когда идеи есть

http://nginx.org/en/books.html

Эээм. Так почему оно читает @aws как файл то?

потому что try_files делает то, что он делает, а не то что вы думаете. дока: Проверяет существование файлов в заданном порядке и использует для обработки запроса первый найденный файл, причём обработка делается в контексте этого же location’а вы думаете: происходит последовательное обращение ко всем $uri с помощью внутреннего перенаправления и в случае 2хх ответа, возвращается.

Но тогда бы все мануалы по настройке PHP не работали, где объявляют @php с проксированием в fpm

а в чем ты тупой? поделись. Бо я тоже ниче крамольного не увидел, нониработаитже

экзекутор нужен правильный жээ ) TAG := $(shell git rev-parse --short HEAD)

location / { error_page 418 = @s3; return 418; } location @s3 { //s3... proxy_pass... error_page 404 = @404_handler; } location @404_handler { root /path/to/404; }

Но тогда бы все мануалы по настройке PHP не работали, где объявляют @php с проксированием в fpm

только последний элемент воспринимается как умный.

поэтому try_files $uri @back; работает, а try_files @back1 @back2; - нет.

Как же тогда подсунуть стандартную страницу ошибки на код 403?

Они где то лежат?

http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_intercept_errors

#nginx #book

экзекутор нужен правильный жээ ) TAG := $(shell git rev-parse --short HEAD)

ай йопт. и правда жи

Но там надо обязательно свой файл пихать

Ниужели нет способа прочто сказать - покажи дефолт

так емое

А хотя наверное я понял... можно через виртуальный локейшен с return 403

proxy_intercept_errors on; и всё.

если error_page не включен, начнут показываться дефолтные ошибки.

У меня так не работает

Щас еще раз перепроверю

Поместил директиву прямо перед proxy_pass

Да, в общем надо включить перехват, объявить @403 { return 403 } и указать его в error_page

Вообще, было бы логично, если бы все именованые локейшены парсились как именованые в try_files

было бы. но нет.

Так эта книжка не то.

Есть какая нить в стиле основы http от простого к сложному

?

RFC?

Нее

Кукбук скорее

какие там основы?

начни с вики, желательно енг, дальше в гугл

meh...

Я не новичок.

Просто понял что хочу систематизировать знания

Книжки в стиле документация по продукту для этого фигово подходят

Коллеги, а ведь бессмысленно делать mysqldump -h remotehost somedb | bzip2 > dump.sql.bz2 && bunzip2 < dump.sql.bz2 | mysql localbase ?

получается дамп сжимается и разжимается локально?

уменьшить io?

Мне тут говорят что это работает в разы быстрее чем без сжатия. Почему?

Должно медленнее работать

ЭЭЭ

БЛЯДЬ ЗАЧЕМ

Допустим со сжатием оно там типо буфферы не забивает или еще что, хз

Но в файл-то зачем

уменьшить io?

да каким образом?

mysqldump <dbname> | mysql <otherdbname>

mysqldump <dbname> | mysql <otherdbname>

Вот, говорят что это медленнее работает

Ну ок

mysqldump <dbname> | bzip2 -c | bzip2 -cd | mysql <otherdbname>

В файл-то зачем!

А, хотя я понял, зачем, кажись

Мы при дампе не ждем прочтения из пайпа

А, хотя там же вообще не пайп, а сдампить и потом всосать

Хз, надо потестить

Мне ща негде

Из прикольных штук, которые действительно быстрее работают, чем общепринятые практики: tar -czf tarball.tgz <list> vs tar -c <list> | gzip > tarball.tgz

Второе работает быстрее

На больших объемах прямо заметно становится

Почему? Два процесса, а не один на одном ядре.

Я померял просто дамп в файл с сжатием 4% cpu 3:23.12 total без сжатия 1% cpu 3:13.99 total

несущественная разница