Re: Проксирование http и https в одном конигурационном файле, на порты отличные от 80 и 443

[mnsold]

Тут наверное я еще не совсем правильно выразился, нужно описать конфигурацию
не то чтобы в одном когфиге, а в одном блоке server {} и без повториний
location {} с разницей только http-https.

Posted at Nginx Forum: 
http://forum.nginx.org/read.php?21,245412,245426#msg-245426

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

Re: Проксирование http и https в одном конигурационном файле, на порты отличные от 80 и 443

[Maxim Dounin]

Hello!

On Wed, Dec 11, 2013 at 10:23:50AM -0500, mnsold wrote:

 Тут наверное я еще не совсем правильно выразился, нужно описать конфигурацию
 не то чтобы в одном когфиге, а в одном блоке server {} и без повториний
 location {} с разницей только http-https.

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

Для того, чтобы избегать повторов - в nginx'е есть наследование 
конфигурации, а равно директива include.  Если этого нехватает - 
обычно правильнее взять в руки любимый шаблонизатор, а не пытаться 
то же самое сделать с помощью условных проверок в процессе 
обработки запросов.

-- 
Maxim Dounin
http://nginx.org/

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

Re: Проксирование http и https в одном конигурационном файле, на порты отличные от 80 и 443

[Andrey Oktyabrskiy]

On 11.12.2013 19:41, mnsold wrote:

server {
listen 80;
...
include app - для http
...
}

server {
listen 443 ssl;
...
include apps - для https
...
}
в этом случае, location /app нужно описывать в 2х файлах
Так и держите location /app в файле location_app, в файлах app и apps 
пишите include location_app;


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

Re: Проксирование http и https в одном конигурационном файле, на порты отличные от 80 и 443

[Maxim Dounin]

Hello!

On Wed, Dec 11, 2013 at 11:58:34AM -0500, mnsold wrote:

[...]

 Согласитесь, N количество блоков  server {} и N количество блоков location
 {} проще изменить, меньше вероятности допустить ошибки и понимать легче, чем
 N*2 количество блоков  server {} и N*2 количество блоков location {}
 сделанных отдельно для http и для https.

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

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

http://nginx.org/en/docs/faq/variables_in_config.html

-- 
Maxim Dounin
http://nginx.org/

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

Re: Проксирование http и https в одном конигурационном файле, на порты отличные от 80 и 443

[Gena Makhomed]

On 11.12.2013 18:58, mnsold wrote:


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

Согласитесь, N количество блоков  server {} и N количество блоков location
{} проще изменить, меньше вероятности допустить ошибки и понимать легче, чем
N*2 количество блоков  server {} и N*2 количество блоков location {}
сделанных отдельно для http и для https.


конфиг nginx - это примерно то же самое, что и ассемблер.

здесь нет макросов, и если нужны макроподстановки, условная компиляция
и другие возможности макроассемблера, их надо будет реализовать 
самостоятельно с помощью m4, python, ruby, perl, awk, sed, и т.п.


следующий уровень - написать свой собственный DSL, аналог
языка высокого уровня, который будет транслироваться
в директивы ассемблера, для их выполнения на nginx.



например, я когда-то делал DSL, который на входе получает
конфиг на языке высокого уровня с очевидным синтаксисом:

h   http://habrahabr.ru/Хабрахабр
gt  http://translate.google.com.ua/ Google Translate
yt  http://youtube.com/ YouTube

(всего - несколько десятков таких записей)

а на выходе транслятора получается конфигурационный файл nginx,
готовый для включения с помощью директивы include, такого вида:

#
# this is auto-generated file, do not edit manually
# config source file: /etc/nginx/conf/redirect.conf
#

server {
server_name h;
server_name h.example.com;
rewrite  ^  http://habrahabr.ru/  redirect;
}

server {
server_name gt;
server_name gt.example.com;
rewrite  ^  http://translate.google.com.ua/  redirect;
}

server {
server_name yt;
server_name yt.example.com;
rewrite  ^  http://youtube.com/  redirect;
}

и страничка /etc/nginx/site/t/index.html
где перечислены все видимые shortcut`ы.

- это используется на сервере, куда указывает * запись в DNS
для домена example.com, чтобы вручную не набирать полный адрес,
а только shortcut`ы h, gt, yt и т.п. это быстро и удобно.

поскольку меня об этом уже спрашивали в прошлый раз -
в аттаче сам конфиг / генератор конфига redirect.conf
и пример его использования в скрипте reload`а nginx.

--
Best regards,
 Gena
#!/bin/bash

nginx -v

/etc/nginx/conf/redirect.conf

service nginx reload

# for pid in $(pgrep nginx); do cat /proc/$pid/limits; done

# for pid in $(pgrep nginx); do grep open /proc/$pid/limits ; done

#!/usr/bin/python
# encoding: utf-8

raw_config = 

yt  http://youtube.com/ YouTube
h   http://habrahabr.ru 
Хабрахабр
dw  http://www.freedrweb.com/   
антивирус Dr.Web CureIt!

t   --- СЃРїРёСЃРѕРє 
всех сокращений

gt  http://translate.google.com.ua/ Google Translate

y   http://www.ya.ru/   ya.ru
yy  http://www.yandex.ru/   yandex.ru

gmail   https://mail.google.com/--- Gmail
kp  http://www.kp.ru/   --- kp.ru

ripehttp://www.ripe.net/--- ripe 
vt  http://www.virustotal.com/ru/   --- VirusTotal



# 
---

conf_header = 
#
# this is auto-generated file, do not edit manually 
# config source file: $config_filename
#

conf_record = 

server {
server_name $name;
server_name $name.example.com;
rewrite  ^  $url  redirect;
}


conf_footer = 


# 
---

html_header = !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01//EN 
http://www.w3.org/TR/html4/strict.dtd;
htmlheadtitleredirect service/title
style type=text/css
a { text-decoration:none; display: block; }
a:link { color: black; }
a:visited { color: black; }
table { border: #00 1px solid; border-collapse: collapse; margin: 0 0 0 0; 
padding 0 0 0 0; } 
tr { margin: 0 0 0 0; padding 0 0 0 0; } 
td { margin: 0 0 0 0; padding 0 0 0 0; } 

table.left { margin-left: 64px; margin-right:auto; }
tr.ff { background-color: #ff; }
tr.ee { background-color: #ee; }
td.name { text-align: right; font-size: x-large; font-family: Courier New; 
font-weight: bold; padding-left: 10px; padding-right: 10px; }
td.desc { text-align: left; font-size: large; font-family: Arial; 
padding-right: 10px; }
div.footer { float: right; }
/style
/headbodytable class=left cellpadding=0 

Re: Проксирование http и https в одном конигурационном файле, на порты отличные от 80 и 443

[mnsold]

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.

Posted at Nginx Forum: 
http://forum.nginx.org/read.php?21,245412,245448#msg-245448

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