Здравствуйте, Maxim.

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

> А чем тебе старый добрый вариант с "error_page 404 = @fallback" не
> угодил?

> Собственно, от try_files его по большому счёту отличает только то,
> что try_files писать чуть проще для разных типичных случаев. (Ну и
> тем, что в отличие от try_files там нет race condition при проверке
> и отдаче файлов, но это тема, интересная только отдельным маньякам
> вроде меня.)

Под кучей if-ов и имел ввиду твой старый добрый вариант. Неправильно
выразился, прошу прощения. Просто хотел заметить, что когда бэкендов
десяток, то конфиг не блещет изяществом и похож на копипасту. Кроме
того такая конструкция не позволяет всякие оптимизации типа выполнения
сразу 10 запросов параллельно вместо последовательного перебора. И
кажется, что работа с бэкендами - это ближе к апстриму.

Ещё придумал третий вариан решения. Задача сейчас симпатичнее
решается, если отделить статусы, вызывающие fail, от статусов,
приводящих к выбору следующего бэкенда. Что-то вроде:

proxy_next_upstream [error | timeout | invalid_header | http_500 | http_502 | http_503 | http_504 | http_404[=not_fail] | off]

Тогда в @fallback можно писать сразу апстрим вместо кучи @fallback-ов
с каждым бэкендом в отдельности. И сразу появляется лаконичность:
попробовали эту группу серверов, если там нету, то пробуем эту.

--
С уважением,
Михаил mailto:postmaster@softsearch.ru

_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru