Maxim Dounin Wrote:
-------------------------------------------------------
> > Согласитесь, N количество блоков server {} и N количество блоков
> location
> > {} проще изменить, меньше вероятности допустить ошибки и понимать
> легче, чем
> > N*2 количество блоков server {} и N*2 количество блоков location {}
> > сделанных отдельно для http и для https.
>
> Не соглашусь. Проще менять то, что само по себе просто. А
> вероятность допустить ошибку - гораздо выше при редактировании
> сложного конфига. Количество - не так важно, и принципиального
> значения не имеет.
>
> Ну и не следует забывать, что все эти попытки "сокращения"
> конфигурации обычно выливаются в множество лишней работы при
> обработке запросов. На всякий случай я оставлю эту ссылку здесь:
>
> http://nginx.org/en/docs/faq/variables_in_config.html


Я с вами тоже тут не соглашусь, т.к. конфиг вида:
server {
listen 80;
listen 443 ssl;
...
include app;
...
}

файл app:
location / {
...
proxy_pass $schema://upstream:;
...
}
Очень простой и то, что вы написали "А вероятность допустить ошибку - гораздо выше при редактировании сложного конфига" тут несколько не уместно, т.к. вы правильно написали чуть выше "само по себе просто" и эти слова очень подходят для данной конфигурации.

Не ясна тогда возможность указывать в директивы в одном блоке server {}
server {
listen 80;
listen 443 ssl;
С ваших слов получается - если удается заставить проксировать по схеме http->http + https->http то можно использовать такую конструкцию, в остальном - ее использовать не правильно, и нужно плодить блоки server{} и location{}.
Я не утверждаю, что именно так вы сказали, это лишь вывод который сделал я на основе ваших наводок.

И конфиг выше уж точно проще чем этот конфиг (как минимум с точки зрения внесения правок, минимизации ошибок, да и не только этого):

server {
listen 80;
...
include app;
...
}

файл app:
location / {
...
proxy_pass http://upstream:;
...
}

server {
listen 443 ssl;
...
include apps;
...
}

файл apps:
location / {
...
proxy_pass https://upstream:;
...
}
Даже с точки зрения "множество лишней работы при обработке запросов" в данном случае:
1сервер+1локейшен(в одном файле)+одна доп. переменная $schema может быть проще в обработке чем 2сервера+2локейшена(в 2х файлах) и в место одной переменной статика в виде http и https.
Это только мысли в слух, они ничем не подтверждены, таких тестов я пока не делал и в серьез их сейчас конечно воспринимать не нужно, но и отказываться от них еще рано.

Максим, вы не подумайте что я вас не понимаю, прекрасно понимаю, но хотелось бы найти решение для вопроса который я озвучивал ранее и был бы признателен за помощь:
как проксировать одно приложение по http и https в одном блоке server {} и одном блоке location {} (без дублей), учитавая, что приложение на бэкэенде может быть доступно как в корне так и по контекстному пути, а порты отличаются от 80 и 443.