from:"CoDDoC"

Непонятки с binary_remote_addr

2019-12-03 Thread CoDDoC


Доброго времени суток!
 
Передаю в php два заголовка:
proxy_set_header 'User-IP' $remote_addr;
proxy_set_header 'BIN-IP'   $binary_remote_addr;
 
Соответственно, на стороне php ловлю их:
$_SERVER ['HTTP_USER_IP']
$_SERVER ['HTTP_BIN_IP']
 
Параллельно пишу значение $binary_remote_addr в лог nginx.
 
В логе nginx все правильно: \xC0\xA8\x00\xC8 (мой IP 192.168.0.200)
 
В php:
*  Конвертирую первый заголовок в bin, затем в hex. На выходе правильно: 
string(8) "c0a800c8"
*  Конвертирую второй заголовок в hex (т.к. он уже bin). На выходе: string(4) 
"c0a8"
Собственно, все. Тупняк. Ткните носом, плз, куда делась половина второго 
заголовка?
Спасибо.
 
--___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Upstream и заголовок Host

2019-01-21 Thread CoDDoC via nginx-ru

Доброе время суток!

Тестовый сервер: test.local. В нем тестовый кластер:
upstream cdn {
    server :;
    server :;
    
}

или:
upstream cdn {
    server cdn001.test.local:;
    server cdn002.test.local:;
    
}

Не принципиально, ибо "cdn001.test.local" резолвится в  и т.д.

Само собой, "proxy_http_version 1.1;" и из какого-то локейшена "proxy_pass 
http://cdn;;
Теперь смотрю, что приходит, например, на выбранный бэкенд.
Ожидаю там увидеть в заголовке Host значение  или 'cdn###.test.local'.
Вижу: http header: "Host: cdn". Что не так?

Входящий контроль проверяет правильность заголовка Host.
Все, что не соответствуют разрешенным, посылаются на 400. Можно, конечно, 
добавить фильтрацию по белому списку, что-то типа "такой-то IP должен прислать 
такой-то заголовок". Но (ИМХО) костыль.

proxy_set_header 'Host' $upstream_addr; - бесполезно.
$upstream_addr получает значение ПОСЛЕ proxy_pass.

Попутно вопрос о $upstream_addr.
Ее можно еще как-то использовать, кроме как в логах? Например, отправить в php, 
но без костылей?

Спасибо.
--___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Вопрос о балансировке нагрузки.

2018-11-30 Thread CoDDoC via nginx-ru


Доброе время суток!

Существует ли в принципе возможность получить в какую-то переменную имя 
бэкенд-сервера, выбранное в директиве upstream?

Задача такая.
Есть основной сервер example.com, на котором: nginx <=> php <=> БД
и несколько бэкендов-хранилок в том же домене, но в разных ДЦ (допустим, 
s1.example.com, s2.example.com и т.д.)
Соответственно:
upstream backends {
    server s1.example.com;
    server s2.example.com;
    server s3.example.com;
    .
}
Пользователь авторизуется на основном сервере, получает сессию и куки.
Каждому пользователю выдаются куки с одинаковами именами, но разными значениями.
Кроме того, для каждого пользователя создаются хэши, привязанные к его сессии и 
кукам.

Требуется отдать с ОСНОВНОГО сервера html, содержащую ссылки вида:
- для пользователя A -  ,
- для пользователя B -  ,

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

Т.е. не пробрасывать запрос на хранилку через proxy_pass backends, а только 
получить имя бэкенда, выбранного с учетом правил в upstream. И получив это имя 
в какую-то переменную, передать его в php, отвечающий за выдачу html страницы 
из соответствующего локейшена.

Заранее благодарю за любые конструктивные идеи.

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

Re[2]: Странная ситуация с levels

2018-11-10 Thread CoDDoC

Да, спасибо.
До переименования зоны я уже догадался.
Но не сразу заметил. Экспериментировал с довольно сложным SSI, пришлось часто 
заглядывать в кэш, многоуровневый оказался неудобен, переключил в один уровень, 
вот только тогда. Потом уже полез в дебаг.

Себе в шпаргалку на заметку. Но все-таки, неплохо было бы сказать в доке о 
рестарте (ИМХО).


>Пятница,  9 ноября 2018, 16:34 +03:00 от Maxim Dounin :
>
>Hello!
>
>On Fri, Nov 09, 2018 at 10:18:30AM +0300, CoDDoC wrote:
>
>> nginx-debug -v
>> nginx version: nginx/1.15.6
>> 
>> Специально обновился, до этого была версия 1.13.12, там то же самое.
>> Изменение levels в proxy_cache_path применяется только после полного 
>> рестарта (service nginx-debug restart)
>> nginx-debug -s reload ожидаемого результата не дает
>> 
>> Как воспроизвести:
>> 1. В контексте http:
>> proxy_cache_path /var/www/html/cache levels=1:2:1 use_temp_path=off 
>> keys_zone=testcache:5m inactive=10m max_size=50m;
>> 2. service nginx-debug restart
>> 3. В error.log:
>> cache manager process  exited with code 0
>> start cache manager process 
>> start cache loader process 
>> 4. Делаю запрос в локейшен, для которого активирована зона testcache
>> 5. Получаю ожидаемое:
>> /var/www/html/cache/3/05/8/e62d74fdc44e220f0225168323c28053
>> 6. Удаляю ветку '3/05/8/e62d74fdc44e220f0225168323c28053'
>> 
>> 7. Меняю levels 1:2:1 -> levels 1
>> 8. nginx-debug -s reload
>> 9. В error.log:
>> cache "testcache" had previously different levels
>> 10. Запрос в тот же локейшен дает тот же результат:
>> /var/www/html/cache/3/05/8/e62d74fdc44e220f0225168323c28053
>> 11. Опять удаляю '3/05/8/e62d74fdc44e220f0225168323c28053'
>> 12. service nginx-debug restart
>> 13. В error.log:
>> cache manager process  exited with code 0
>> start cache manager process 
>> start cache loader process 
>> 14. Запрос в тот же локейшен опять дает ожидаемое:
>> /var/www/html/cache/3/e62d74fdc44e220f0225168323c28053
>> 
>> Если это нормальное поведение, может, имеет смысл как-то отметить в 
>> документации необходимость рестарта?
>
>Это нормальное поведение.
>
>Многие вещи, работа с которыми происходит через зоны разделяемой 
>памяти из всех процессов, поменять без пересоздания зоны 
>разделяемой памяти - нельзя.  Наиболее банальный пример - нельзя 
>поменять собственно размер зоны разделяемой памяти.
>
>В чуть более сложных случаях - нельзя менять параметры, которые 
>меняют поведение рабочих процессов на несовместимое с другими 
>рабочими процессами или с уже имеющейся в разделяемой памяти 
>информацией.  В частности, levels в кэше - определяют, в каком 
>именно виде лежат данные на диске, и каким именно файлам на диске 
>соответствуют элементы в разделяемой памяти.  То есть поменять 
>levels просто так нельзя - фактически, надо выкинуть из памяти всю 
>информацию, которая становится негодной, и презагрузить содержимое 
>кэша заново.  Кроме того, всё ещё осложняется тем, что у нас есть 
>старые рабочи процессы, которые могут работать неопределённо 
>долго, и эти рабочие процессы предполагают старое значение levels, то 
>есть если мы таки выкинем и перезагрузим содержимое разделяемой 
>памяти - начнут вести себя некорретно они.
>
>Чтобы подобных проблем не возникало - при применении новой 
>конфигурации nginx проверяет, что конфигурация совместима с тем, 
>как использовались зоны разделяемой памяти ранее.  И если 
>обнаруживает, что попытались поменять что-то, что менять нельзя - 
>логгирует соответствующую ошибку в error log, и откатывается к 
>старой конфигурации.
>
>Если тем не менее хочется соответствующие параметры поменять, то 
>это можно сделать одним из следующих способов:
>
>- Переименовать зону разделяемой памяти (в случае кэша - лучше 
>  при этом заодно задать новый путь), и использовать её в 
>  конфигурации с новыми параметрами.  При таком изменении 
>  конфликтов между старой и новой конфигурацией не будет, можно 
>  будет сделать reload.  И при этом сохранится содержимое 
>  остальных зон разделяемой памяти, конфигурацию которых не меняли.
>
>- Сделать binary upgrade.  При этом все зоны разделяемой памяти будут 
>  созданы заново, однако потерь запросов не будет.
>
>- Ну и собственно сделать restart.  Всё тоже заработает с новой 
>  конфигурацией, но смысла в этом приблизительно никакого - binary 
>  upgrade даст тот же результат, но без потери запросов.
>
>-- 
>Maxim Dounin
>http://mdounin.ru/
>___
>nginx-ru mailing list
>nginx-ru@nginx.org
>http://mailman.nginx.org/mailman/listinfo/nginx-ru


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

Странная ситуация с levels

2018-11-08 Thread CoDDoC

nginx-debug -v
nginx version: nginx/1.15.6

Специально обновился, до этого была версия 1.13.12, там то же самое.
Изменение levels в proxy_cache_path применяется только после полного рестарта
(service nginx-debug restart)
nginx-debug -s reload ожидаемого результата не дает

Как воспроизвести:
1. В контексте http:
proxy_cache_path /var/www/html/cache levels=1:2:1 use_temp_path=off
keys_zone=testcache:5m inactive=10m max_size=50m;
2. service nginx-debug restart
3. В error.log:
cache manager process exited with code 0
start cache manager process
start cache loader process
4. Делаю запрос в локейшен, для которого активирована зона testcache
5. Получаю ожидаемое:
/var/www/html/cache/3/05/8/e62d74fdc44e220f0225168323c28053
6. Удаляю ветку '3/05/8/e62d74fdc44e220f0225168323c28053'

7. Меняю levels 1:2:1 -> levels 1
8. nginx-debug -s reload
9. В error.log:
cache "testcache" had previously different levels
10. Запрос в тот же локейшен дает тот же результат:
/var/www/html/cache/3/05/8/e62d74fdc44e220f0225168323c28053
11. Опять удаляю '3/05/8/e62d74fdc44e220f0225168323c28053'
12. service nginx-debug restart
13. В error.log:
cache manager process exited with code 0
start cache manager process
start cache loader process
14. Запрос в тот же локейшен опять дает ожидаемое:
/var/www/html/cache/3/e62d74fdc44e220f0225168323c28053

Если это нормальное поведение, может, имеет смысл как-то отметить в
документации необходимость рестарта?

Спасибо.
--___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re[6]: Запуск php скриптов из разных директории

2018-06-29 Thread CoDDoC


Не знаю насчет бредовости, но такое ощущение. что вы не совсем четко ее 
понимаете для себя.

1. Пользак - админ на своем ВПС. Вы - админ хоста.

2. Если пользак имеет доступ ФТП к директории /home/admin на ВПС, он может 
слить себе любой пхп файл.
Другой вариант, как он может это сделать - если у него есть шелл. Но вы можете 
положить пхп в '/home/user', а фтп дать '/home/user/ftp'. Технически, не важно, 
какие запросы делает пользак. Точнее, он может делать запросы, только 
разрешенные админом.
Важно, чтобы для всех правильных (с вашей точки зрения) запросов существовали 
локейшены. Тогда все запросы, для которых не нашлось подходящего локейшена 
считаем не правильными. Я обычно для таких заходов создаю мусорку типа:
location "" { return 404 ;}
Ее можно и логировать отдельно при желании.

3. Считаем, что пользак имеет ФТП только на '/home/user' , выше не поднимается. 
Вам нужно дать ему админку ЦМС, которая лежит в '/home/admin'. Т.е. пользак 
делает входящий запрос как /user и получает ответом хтмл - результат 
работы /home/admin/index.php .Но запрос может быть и такой: 
/admin/index.php, тогда беда.

Для этого и нужно проксировать запрос на бэкенд. Я ж вам сразу сказал изучайте 
location, rewrite, map и регексы.
Простой пример.
Допустим, входящий запрос /user
На него нужно дать ответом хтмл как результат работы /admin/index.php

location /user {
    rewrite "^/user$" /admin/index.php break;
    try_files   $uri
    =404
    ;
    proxy_pass <здесь ваш бэкенд>;
}

"^/user$" в кавычках, потому что здесь возможны варианты (реальный формат 
запроса, параметры и т.п.).

В довесок, для явного указания htm или php в запросе:
location ~ (\.html$|\.php$) { internal; }



>Пятница, 29 июня 2018, 17:36 +03:00 от al3x < nginx-fo...@forum.nginx.org >:
>
>Я уже начинаю думать, что у меня какая-то бредовая идея... еще немного и я
>откажусь от нее =)
>Не знаю как еще объяснить, но попробую...
>
>Есть файлы CMS:
>/home/admin/index.php
>/home/admin/modules/module.php
>/home/admin/template/news.html
>/home/admin/template/style.css
>
>Директория юзера:
>/home/user/ - у юзера есть доступ только к этой директории.
>
>При обращении по IP сервера nginx сначала смотрит в /home/user/ и если не
>находит там index.php, то смотрит в /home/admin/index.php и отдает его.
>
>Далее /home/admin/index.php выполняет свою работу и хочет обработать файл
>template/news.html. Nginx должен проверить, нет ли этого файла в директории
>юзера /home/user/template/news.html и если есть, то отдать его. Если этого
>файла нет, то отдать из папки /home/admin/template/news.html
>
>Затем юзер захотел создать свой личный модуль и положил его в папку
>/home/user/modules/new_module.php
>и когда /home/admin/index.php загружает модули из папки /modules/ то nginx
>должен сначала проверить все файлы в директории юзера /home/user/modules/, а
>затем здесь /home/admin/modules/ и таким образом подгрузить для PHP все
>модули из двух директорий, словно из одной.
>
>Т.е. директории должны быть как бы зеркалами друг друга.
>
>Это возможно сделать?
>
>Dmitriy Lyalyuev Wrote:
>---
>> Может я чего не понимаю, но может стоит сделать локейшн типа
>> /user_content
>> и рут выставить в хомяк юзера?
>> Туда же и ФТП пусть смотрит с ограничением юзера в этом каталоге.
>> А все остальное юзеру не будет доступно от слова совсем.
>> 
>> Задача простая как 3 копейки и слабо имеет отношение к  Nginx.
>> Или я чего-то не понимаю?
>> ___
>> nginx-ru mailing list
>>  nginx-ru@nginx.org
>>  http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
>Posted at Nginx Forum:  
>https://forum.nginx.org/read.php?21,280329,280339#msg-280339
>
>___
>nginx-ru mailing list
>nginx-ru@nginx.org
>http://mailman.nginx.org/mailman/listinfo/nginx-ru


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

Re[4]: Запуск php скриптов из разных директории

2018-06-29 Thread CoDDoC


Как-то все больше запутывается.
Если речь о ВПС - так это один сервер на одного пользака, остальные туда 
доступа не имеют.
https://ru.wikipedia.org/wiki/VPS  
Или речь о нескольких пользаках в рамках одной ЦМС на одном физическом сервере? 
Или о виртхостах в рамках одного сервера?

Насчет ионкуба - загуглите два слова 'ioncube decoder'

При любом раскладе (ИМХО), позволять пользаку запускать ПХП и жабу даже из его 
хоум папки небезопасно. Ибо шелл-скрипты никто не отменял. Тогда нужен чрут на 
его хоум. А еще лучше - так это заготовить пользаку жабоскрипты и разрешить ему 
только ХТМЛ. В противном случае вы рискуете, что пользак вполне сможет пролезть 
к вам в ФС со всеми вытекающими.






>Пятница, 29 июня 2018, 13:20 +03:00 от al3x < nginx-fo...@forum.nginx.org >:
>
>Для юзера создается отдельная VPS с USER правами и доступом ФТП к своей
>директории (/home/user/)
>
>В директории /home/admin/ находится ПО (CMS), которое юзер будет
>арендовать.
>
>При обращении к IP сервера в браузере ему будет доступен веб интерфейс ПО.
>
>Но если юзер создает какие-либо файлы в своей директории (/home/user/), то
>nginx должен сначала отдать их, а потом уже файлы ПО.
>
>Защитить от скачивания нужно именно PHP файлы ПО. Но даже если юзер сможет
>скачать пару php-файлов - не страшно, т.к. они будут под ионкубом. Возможно
>еще придется отключить какие-то php функции...
>
>
>Если такое организовать не получится, то можно немного изменить задачу и
>обрабатывать PHP только в /home/admin/, а в /home/user/ отдавать статику -
>js, css, картинки и тд., но оставить возможность обрабатывать PHP только в
>одной папке, например, /home/user/scripts/
>
>В общем нужно каким-то образом сдавать ПО в аренду, без особого ущемления
>действий юзера. У него должна быть возможность править шаблоны в CMS-ке,
>ИСПОЛЬЗУЯ СВОЙ ФТП-ДОСТУП, и загружать в эти шаблоны всякие js и тд.
>
>
>CoDDoC Wrote:
>---
>> По-моему, вы слишком усложняете.
>> При чем здесь вообще фтп?
>> И какие файлы пользак не должен скачивать? ПХП? Так в данном случае у
>> него как раз есть такая возможность.
>> ХТМЛ? - А как иначе у пользака должен работать веб интерфейс?
>> Жаба и ЦСС? - Так они обфусцируются и падают в кеш пользаку.
>> 
>> Уточните задачу.
>
>Posted at Nginx Forum:  
>https://forum.nginx.org/read.php?21,280329,280334#msg-280334
>
>___
>nginx-ru mailing list
>nginx-ru@nginx.org
>http://mailman.nginx.org/mailman/listinfo/nginx-ru


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

Re[2]: Запуск php скриптов из разных директории

2018-06-29 Thread CoDDoC

По-моему, вы слишком усложняете.
При чем здесь вообще фтп?
И какие файлы пользак не должен скачивать? ПХП? Так в данном случае у него как 
раз есть такая возможность.
ХТМЛ? - А как иначе у пользака должен работать веб интерфейс?
Жаба и ЦСС? - Так они обфусцируются и падают в кеш пользаку.

Уточните задачу.


>Пятница, 29 июня 2018, 10:06 +03:00 от al3x :
>
>Суть в том, что пользователю нужно предоставить для пользования ПО, которое
>бы он не смог скачать. При этом у него есть фтп доступ к своей директории.
>Даже если юзер скачает один-два файла - они будут закодированы, поэтому, не
>зная структуры всего ПО, он не доберется до остальных.
>
>Я знаю, что if не содержит ветки else. Выше я написал просто для
>наглядности, чтобы как-то правильно перевести в формат nginx.
>
>Вот что я пробовал, но пока ничего не получается:
>
>root/home/user;
>
>location / {
> try_files $uri @fallback_all;
>}
>
>location @fallback_all {
> root /home/admin;
> try_files $uri @fallback_php;
>}
>
>location @fallback_php {
> root /home/admin;
>
> if (!-f $document_root$fastcgi_script_name) {return  404;}
> fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
> fastcgi_pass127.0.0.1:9032;
> fastcgi_index   index.php;
> include /etc/nginx/fastcgi_params;
>}
>
>
>Конфиг для "одиночного" режима:
>
>location / {
>  index index.php;
>  try_files $uri $uri/ /index.php?$query_string;
>}
>
>location /admin {
>  try_files $uri /admin/index.php?$query_string;
>}
>
>location ~ [^/]\.php(/|$) {
>  fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
>  if (!-f $document_root$fastcgi_script_name) {
>return  404;
>  }
>  fastcgi_pass127.0.0.1:9023;
>  fastcgi_index   index.php;
>  include /etc/nginx/fastcgi_params;
>}
>
>Posted at Nginx Forum:  
>https://forum.nginx.org/read.php?21,280329,280331#msg-280331
>
>___
>nginx-ru mailing list
>nginx-ru@nginx.org
>http://mailman.nginx.org/mailman/listinfo/nginx-ru


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

Re: Запуск php скриптов из разных директории

2018-06-28 Thread CoDDoC

И вам не хворать.
УФФ...
Во-первых, конструкция if не содержит ветки else. В ПРИНЦИПЕ!
Во-вторых, если не понимаете, как работает if, лучше не юзайте, словите кучу 
проблем. То же самое относится к try_files.
В-третьих, как минимум, вам нужно разделить запросы на 2 группы: админские и 
юзерские. Или по какому-то признаку с обработкой в пхп контроллере, или чтобы 
они падали в разные локейшены.

Для этого изучайте location, rewrite, map и регексы (тоже, как минимум).

Юзер может запускать админские скрипты? Жэсть!!!


>Четверг, 28 июня 2018, 22:19 +03:00 от al3x :
>
>Здравствуйте,
>
>имеются директории:
>
>/home/admin/ - в этой папке находятся файлы (напр. index.php, conf.php,
>admin/index.php), которые нужно скрыть от юзера (но запускать он их может).
>/home/user/ - в этой папке файлы юзера.
>
>Задача:
>
>ЕСЛИ (запрошенный http адрес соответствует файлу в папке /home/user/)
>{
>ТО вернуть клиенту этот файл
>}
>ИНАЧЕ
>{
>ЕСЛИ (файл /home/user/index.php существует)
>{
>ТО вызвать скрипт /home/user/index.php для обработки запроса
>}
>ИНАЧЕ
>{
>указать root -директорию /home/admin/ и
>
>ЕСЛИ (запрошенный http адрес соответствует файлу в папке /home/admin/)
>{
>ТО вернуть клиенту этот файл
>}
>ИНАЧЕ
>{
>вызвать скрипт /home/admin/index.php для обработки запроса
>}
>}
>}
>
>
>Т.е. если юзер создает файл, например, /home/user/index.php, то при открытии
>сайта должен запускаться именно этот файл. Если же этого файла нет, то
>запускаться должен /home/admin/index.php и тд. При этом в папках кроме
>php-файлов могут находиться файлы css, картинки и другие.
>
>Подскажите пожалуйста рабочий конфиг для такой задачи.
>
>Пробовал через try_files пока ничего не получается...
>
>Posted at Nginx Forum:  
>https://forum.nginx.org/read.php?21,280329,280329#msg-280329
>
>___
>nginx-ru mailing list
>nginx-ru@nginx.org
>http://mailman.nginx.org/mailman/listinfo/nginx-ru


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

Re[2]: О заголовке content-type

2018-02-19 Thread CoDDoC

А... голова дырявая. Забыл про types.
Спасибо.

>Понедельник, 19 февраля 2018, 19:26 +03:00 от Maxim Dounin 
><mdou...@mdounin.ru>:
>
>Hello!
>
>On Mon, Feb 19, 2018 at 06:18:52PM +0300, CoDDoC wrote:
>
>> Доброе время суток!
>> 
>> Есть такой локейшен:
>> location ~ "^/img/" { internal; }
>> 
>> Естественно, прямой запрос 'GET /img/file.jpg' получает 404
>> Все хорошо, но нужно вместо стандартной nginx страницы отдать кастомную.
>> Можно решать разными способами, я решил попробовать через 'return 404 
>> ' (минимум внутренних реврайтов/редиректов).
>> 
>> Получилось так (упрощенно):
>> 
>> error_page 404 = @err404;
>> location @err404 {
>>   return 404 ' WTF ? 
>>';
>>   add_header "Content-Type" "text/html; charset=UTF-8" always;
>> }
>> 
>> Оно работает, одно смущает: дублирование заголовка Content-Type: сперва 
>> 'image/jpeg', затем уже 'text/html; charset=UTF-8'
>> Браузер-то, ясное дело, возьмет по итогу второй заголовок. Но, может, есть 
>> какой-либо цивилизованный способ оставить один Content-Type без 
>> прикручивания костыля типа headers-more ?
>
>Правильно - не пытаться прибить левый Content-Type гвоздями с 
>помощью add_header, а задать его штатными средствами.  Например 
>так:
>
>error_page 404 = /error404.html;
>location = /error404.html {
>charset utf-8;
>return 404 ' ...';
>}
>
>Или, если по каким-то причинам очень хочется именно именованный 
>location, то так:
>
>error_page 404 = @err404;
>location @err404 {
>types {}
>default_type text/html;
>charset utf-8;
>return 404 ' ...';
>}
>
>-- 
>Maxim Dounin
>http://mdounin.ru/
>___
>nginx-ru mailing list
>nginx-ru@nginx.org
>http://mailman.nginx.org/mailman/listinfo/nginx-ru


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

О заголовке content-type

2018-02-19 Thread CoDDoC

Доброе время суток!

Есть такой локейшен:
location ~ "^/img/" { internal; }

Естественно, прямой запрос 'GET /img/file.jpg' получает 404
Все хорошо, но нужно вместо стандартной nginx страницы отдать кастомную.
Можно решать разными способами, я решил попробовать через 'return 404 ' 
(минимум внутренних реврайтов/редиректов).

Получилось так (упрощенно):

error_page 404 = @err404;
location @err404 {
  return 404 ' WTF ?  
  ';
  add_header "Content-Type" "text/html; charset=UTF-8" always;
}

Оно работает, одно смущает: дублирование заголовка Content-Type: сперва 
'image/jpeg', затем уже 'text/html; charset=UTF-8'
Браузер-то, ясное дело, возьмет по итогу второй заголовок. Но, может, есть 
какой-либо цивилизованный способ оставить один Content-Type без прикручивания 
костыля типа headers-more ?

proxy_hide_header не годится - нет проксирования. Отправлять все 
"не-пойми-какие" запросы на бэкенд - не вижу в этом  особого смысла.

Спасибо.
--___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re[6]: nginx restart AND listen ip:port

2018-02-14 Thread CoDDoC

Третий и последний раз повторяю, хотите, чтобы вам помогли - обозначайте ВСЕ 
части конфига, отвечающие за проблему. То, что по вашему мнению должно 
работать, но не работает.
Вы видите разницу в ваших локейшенах?
Апстрим backend у вас как-то определен?
В error.log, случаем, не проскакивает что-то типа 'host not found in upstream 
...' ?
И, кстати, все-же рекомендую перечитывать конфиг как 'nginx -s reload'. Так вы 
сразу увидите ошибку. 'service nginx reload' вам ответит ОК, а ошибку скинет в 
лог.


>Среда, 14 февраля 2018, 19:13 +03:00 от "imsystem" 
><nginx-fo...@forum.nginx.org>:
>
>Всё проксирует, при записи
>server {
>listen external_IP_nginx:443;
>location / { proxy_pass https://local_IP_IIS; }
>}
>
>При этой записи не проксирует, выдавало, насколько помню, 403
>server {
>listen 443;
>location / { proxy_pass https://backend; }
>}
>
>А прочие команды я и в документации видел, просто через service/systemctl
>как-то привычнее.
>
>CoDDoC Wrote:
>---
>> Да, сопоставима. Просто вы об этом ничего не сказали.
>> Насчет опции -s и прочих можете посмотреть nginx -h
>> Будет что-то типа:
>> nginx version: nginx/1.13.8
>> Usage: nginx [-?hvVtTq] [-s signal] [-c filename] [-p prefix] [-g
>> directives]
>> 
>> Options:
>>   -?,-h : this help
>>   -v    : show version and exit
>>   -V    : show version and configure options then exit
>>   -t    : test configuration and exit
>>   -T    : test configuration, dump it and exit
>>   -q    : suppress non-error messages during configuration
>> testing
>>   -s signal : send signal to a master process: stop, quit, reopen,
>> reload
>>   -p prefix : set prefix path (default: /etc/nginx/)
>>   -c filename   : set configuration file (default:
>> /etc/nginx/nginx.conf)
>>   -g directives : set global directives out of configuration file
>> 
>> По остальному вам Максим ответил.
>> 
>> А почему не проксирует - я вам уже сказал. С такой скудной
>> информацией, что вы даете, нужен хрустальный шар. Не нужно вываливать
>> весь конфиг, достаточно частей, относящихся к теме. Причин на самом
>> деле может быть много. Начиная от правил FW и заканчивая локейшеном, в
>> который падает запрос.
>> 
>> 
>> >Среда, 14 февраля 2018, 15:51 +03:00 от "imsystem"
>> < nginx-fo...@forum.nginx.org >:
>> >
>> >> Вам обязательно 'service nginx restart'?
>> >> 'nginx -s reload' пробовали?
>> >Нет, не обязательно.
>> >Нет, не пробовал, считал её сопоставимой команде service nginx
>> reload, а она
>> >работает.
>> >Меня сам факт смущает.
>> >
>> >> Насчет версии 1.12.1. В stable ветке доступна 1.12.2. Может там уже
>> >> пофиксили?
>> >Может и пофиксили.
>> >
>> >> >> Два интерфейса внешний и локальный. Везде ip - внешний ip.
>> >> >> Проксирование идёт по локалке.
>> >> >> Если принудительно не указывать ip в listen, то не проксируется.
>> >> Потрудитесь четко формулировать вопрос.
>> >> Что и куда вы проксируете? nginx на nginx? 80-й порт на 443-й?
>> Бэкенд
>> >> где находится? На том же сервере или на другом?
>> >> ip  в конфиге внешние?
>> >С nginx на IIS, сервера разные, 80 порт перенаправляется на 443 (http
>> ->
>> >https).
>> >ip которые слушает nginx внешние, проксирует соответственно на
>> локальный ip
>> >IIS потоо https прколу.
>> >
>> >
>> >> >Среда, 14 февраля 2018, 13:10 +03:00 от "imsystem"
>> >> <  nginx-fo...@forum.nginx.org >:
>> >> >
>> >> >И совсем забыл.
>> >> >
>> >> >nginx -V
>> >> >nginx version: nginx/1.12.1
>> >> >built by gcc 6.3.0 20170516 (Debian 6.3.0-18)
>> >> >built with OpenSSL 1.1.1-dev  xx XXX 
>> >> >TLS SNI support enabled
>> >> >configure arguments: --prefix=/usr/local/nginx/
>> >> >--conf-path=/etc/nginx/nginx.conf
>> >> --error-log-path=/var/log/nginx/error.log
>> >> >--http-log-path=/var/log/nginx/access.log
>> >> --pid-path=/var/run/nginx.pid
>> >> >--user=www-data --group=www-data --with-threads --with-file-aio
>> >> >--with-http_ssl_module --with-openssl=/home/sysadmin/src/openssl
>> >> >--with-http_v2_module --with-http_realip_module
>> >> --with-http_addition_module
&g

Re[4]: nginx restart AND listen ip:port

2018-02-14 Thread CoDDoC

Да, сопоставима. Просто вы об этом ничего не сказали.
Насчет опции -s и прочих можете посмотреть nginx -h
Будет что-то типа:
nginx version: nginx/1.13.8
Usage: nginx [-?hvVtTq] [-s signal] [-c filename] [-p prefix] [-g directives]

Options:
  -?,-h : this help
  -v    : show version and exit
  -V    : show version and configure options then exit
  -t    : test configuration and exit
  -T    : test configuration, dump it and exit
  -q    : suppress non-error messages during configuration testing
  -s signal : send signal to a master process: stop, quit, reopen, reload
  -p prefix : set prefix path (default: /etc/nginx/)
  -c filename   : set configuration file (default: /etc/nginx/nginx.conf)
  -g directives : set global directives out of configuration file

По остальному вам Максим ответил.

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


>Среда, 14 февраля 2018, 15:51 +03:00 от "imsystem" 
>:
>
>> Вам обязательно 'service nginx restart'?
>> 'nginx -s reload' пробовали?
>Нет, не обязательно.
>Нет, не пробовал, считал её сопоставимой команде service nginx reload, а она
>работает.
>Меня сам факт смущает.
>
>> Насчет версии 1.12.1. В stable ветке доступна 1.12.2. Может там уже
>> пофиксили?
>Может и пофиксили.
>
>> >> Два интерфейса внешний и локальный. Везде ip - внешний ip.
>> >> Проксирование идёт по локалке.
>> >> Если принудительно не указывать ip в listen, то не проксируется.
>> Потрудитесь четко формулировать вопрос.
>> Что и куда вы проксируете? nginx на nginx? 80-й порт на 443-й? Бэкенд
>> где находится? На том же сервере или на другом?
>> ip  в конфиге внешние?
>С nginx на IIS, сервера разные, 80 порт перенаправляется на 443 (http ->
>https).
>ip которые слушает nginx внешние, проксирует соответственно на локальный ip
>IIS потоо https прколу.
>
>
>> >Среда, 14 февраля 2018, 13:10 +03:00 от "imsystem"
>> < nginx-fo...@forum.nginx.org >:
>> >
>> >И совсем забыл.
>> >
>> >nginx -V
>> >nginx version: nginx/1.12.1
>> >built by gcc 6.3.0 20170516 (Debian 6.3.0-18)
>> >built with OpenSSL 1.1.1-dev  xx XXX 
>> >TLS SNI support enabled
>> >configure arguments: --prefix=/usr/local/nginx/
>> >--conf-path=/etc/nginx/nginx.conf
>> --error-log-path=/var/log/nginx/error.log
>> >--http-log-path=/var/log/nginx/access.log
>> --pid-path=/var/run/nginx.pid
>> >--user=www-data --group=www-data --with-threads --with-file-aio
>> >--with-http_ssl_module --with-openssl=/home/sysadmin/src/openssl
>> >--with-http_v2_module --with-http_realip_module
>> --with-http_addition_module
>> >--with-http_xslt_module --with-http_image_filter_module
>> >--with-http_geoip_module --with-http_sub_module
>> --with-http_dav_module
>> >--with-http_flv_module --with-http_mp4_module
>> --with-http_gunzip_module
>> >--with-http_gzip_static_module --with-http_auth_request_module
>> >--with-http_random_index_module --with-http_secure_link_module
>> >--with-http_degradation_module --with-http_slice_module
>> >--with-http_stub_status_module --with-stream --with-stream_ssl_module
>> >
>> >uname -a
>> >Linux gateway 4.9.0-4-amd64 #1 SMP Debian 4.9.65-3+deb9u1
>> (2017-12-23)
>> >x86_64 GNU/Linux
>> >
>> >Posted at Nginx Forum: 
>>  https://forum.nginx.org/read.php?21,278548,278550#msg-278550
>> >
>> >___
>> >nginx-ru mailing list
>> > nginx-ru@nginx.org
>> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
>> 
>> 
>> --
>> ___
>> nginx-ru mailing list
>>  nginx-ru@nginx.org
>>  http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
>Posted at Nginx Forum:  
>https://forum.nginx.org/read.php?21,278551,278554#msg-278554
>
>___
>nginx-ru mailing list
>nginx-ru@nginx.org
>http://mailman.nginx.org/mailman/listinfo/nginx-ru


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

Re[2]: nginx restart AND listen ip:port

2018-02-14 Thread CoDDoC

Вам обязательно 'service nginx restart'?
'nginx -s reload' пробовали?

Насчет версии 1.12.1. В stable ветке доступна 1.12.2. Может там уже пофиксили?

>> Два интерфейса внешний и локальный. Везде ip - внешний ip.
>> Проксирование идёт по локалке.
>> Если принудительно не указывать ip в listen, то не проксируется.
Потрудитесь четко формулировать вопрос.
Что и куда вы проксируете? nginx на nginx? 80-й порт на 443-й? Бэкенд где 
находится? На том же сервере или на другом?
ip  в конфиге внешние?


>Среда, 14 февраля 2018, 13:10 +03:00 от "imsystem" 
>:
>
>И совсем забыл.
>
>nginx -V
>nginx version: nginx/1.12.1
>built by gcc 6.3.0 20170516 (Debian 6.3.0-18)
>built with OpenSSL 1.1.1-dev  xx XXX 
>TLS SNI support enabled
>configure arguments: --prefix=/usr/local/nginx/
>--conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log
>--http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid
>--user=www-data --group=www-data --with-threads --with-file-aio
>--with-http_ssl_module --with-openssl=/home/sysadmin/src/openssl
>--with-http_v2_module --with-http_realip_module --with-http_addition_module
>--with-http_xslt_module --with-http_image_filter_module
>--with-http_geoip_module --with-http_sub_module --with-http_dav_module
>--with-http_flv_module --with-http_mp4_module --with-http_gunzip_module
>--with-http_gzip_static_module --with-http_auth_request_module
>--with-http_random_index_module --with-http_secure_link_module
>--with-http_degradation_module --with-http_slice_module
>--with-http_stub_status_module --with-stream --with-stream_ssl_module
>
>uname -a
>Linux gateway 4.9.0-4-amd64 #1 SMP Debian 4.9.65-3+deb9u1 (2017-12-23)
>x86_64 GNU/Linux
>
>Posted at Nginx Forum:  
>https://forum.nginx.org/read.php?21,278548,278550#msg-278550
>
>___
>nginx-ru mailing list
>nginx-ru@nginx.org
>http://mailman.nginx.org/mailman/listinfo/nginx-ru


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

Re[2]: В каком порядке обрабатываются location?

2018-02-12 Thread CoDDoC

А..., вон оно как... А я голову сломал, почему локейшены откуда-то с середины 
выдергиваются.
Еще раз спасибо.


>Понедельник, 12 февраля 2018, 17:17 +03:00 от Maxim Dounin 
><mdou...@mdounin.ru>:
>
>Hello!
>
>On Mon, Feb 12, 2018 at 04:58:32PM +0300, CoDDoC wrote:
>
>> >> location /456/ оказался в корне дерева, и поэтому проверяется первым.
>> А почему именно этот? Можно поподробнее?
>
>Потом что он находится в середине списка location'ов, 
>отсортированного строково.  Такой подход позволяет минимизировать 
>количество необходимых сравнений: если строковое сравнение URI 
>запроса с /456/ говорит, что URI меньше, то дальнейший поиск 
>нужного location'а будет делаться только среди location'ов, 
>которые меньше /456/.
>
>-- 
>Maxim Dounin
>http://mdounin.ru/
>___
>nginx-ru mailing list
>nginx-ru@nginx.org
>http://mailman.nginx.org/mailman/listinfo/nginx-ru


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

Re[2]: В каком порядке обрабатываются location?

2018-02-12 Thread CoDDoC

>> location /456/ оказался в корне дерева, и поэтому проверяется первым.
А почему именно этот? Можно поподробнее?

Спасибо.

>Понедельник, 12 февраля 2018, 16:52 +03:00 от Maxim Dounin 
><mdou...@mdounin.ru>:
>
>Hello!
>
>On Mon, Feb 12, 2018 at 04:31:18PM +0300, CoDDoC wrote:
>
>> Доброе время суток!
>> Слегка запутался в порядке обработки локейшенов.
>> Такая структура:
>> 
>> /1/index.html
>> /23/index.html
>> /456/index.html
>> /7890/index.html
>> 
>> Все файлы index.html, естественно, разные.
>> 
>> Соответственно, тестовый конфиг:
>> 
>> server {
>>     
>>     location = /1/ { rewrite ^ /1/index.html break; }
>>     location = /23/ { rewrite ^ /23/index.html break; }
>>     location = /456/ { rewrite ^ /456/index.html break; }
>>     location = /7890/ { rewrite ^ /7890/index.html break; }
>
>[...]
>
>> Т.е. работает-то оно правильно, но проверки существующих 
>> локейшенов почему-то всегда начинаюся с "/456/". Не понимаю, чем 
>> он такой особенный? Если отталкиваться от длины, так самый 
>> длинный "/7890/"
>
>Префиксные location'ы не проверяются последовательно, а строится 
>дерево, и поиск максимально совпадающего location'а делается 
>проходом по дереву.  В вашем случае location /456/ оказался в 
>корне дерева, и поэтому проверяется первым.
>
>-- 
>Maxim Dounin
>http://mdounin.ru/
>___
>nginx-ru mailing list
>nginx-ru@nginx.org
>http://mailman.nginx.org/mailman/listinfo/nginx-ru


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

В каком порядке обрабатываются location?

2018-02-12 Thread CoDDoC


Доброе время суток!
Слегка запутался в порядке обработки локейшенов.
Такая структура:

/1/index.html
/23/index.html
/456/index.html
/7890/index.html

Все файлы index.html, естественно, разные.

Соответственно, тестовый конфиг:

server {
    
    location = /1/ { rewrite ^ /1/index.html break; }
    location = /23/ { rewrite ^ /23/index.html break; }
    location = /456/ { rewrite ^ /456/index.html break; }
    location = /7890/ { rewrite ^ /7890/index.html break; }

    location ~ (\.html$|\.php$) { internal; }

    location "" { return 404; }

    error_page 404 = @err404;

    # все, что не соответствует
    location @err404 {
    keepalive_timeout 0;
    rewrite ^ /err/404.html break;
    }
}

Из дебага:

2018/02/12 16:02:05 [debug] 11200#11200: *1 http request line: "GET /1/ 
HTTP/1.1"
2018/02/12 16:02:05 [debug] 11200#11200: *1 http uri: "/1/"

2018/02/12 16:02:05 [debug] 11200#11200: *1 test location: ""
<<< === здесь ожидалось test location: "/7890/", как локейшен максимальной длины
2018/02/12 16:02:05 [debug] 11200#11200: *1 test location: "/456/"
2018/02/12 16:02:05 [debug] 11200#11200: *1 test location: "/23/"
2018/02/12 16:02:05 [debug] 11200#11200: *1 test location: "/1/"
2018/02/12 16:02:05 [debug] 11200#11200: *1 using configuration "=/1/"

=

2018/02/12 16:03:05 [debug] 11246#11246: *1 http request line: "GET /23/ 
HTTP/1.1"
2018/02/12 16:03:05 [debug] 11246#11246: *1 http uri: "/23/"

2018/02/12 16:03:05 [debug] 11246#11246: *1 test location: ""
<<< === здесь также ожидалось test location: "/7890/", как локейшен 
максимальной длины
2018/02/12 16:03:05 [debug] 11246#11246: *1 test location: "/456/"
2018/02/12 16:03:05 [debug] 11246#11246: *1 test location: "/23/"
2018/02/12 16:03:05 [debug] 11246#11246: *1 using configuration "=/23/"

===

2018/02/12 16:03:51 [debug] 11283#11283: *1 http request line: "GET /456/ 
HTTP/1.1"
2018/02/12 16:03:51 [debug] 11283#11283: *1 http uri: "/456/"

2018/02/12 16:03:51 [debug] 11283#11283: *1 test location: ""
2018/02/12 16:03:51 [debug] 11283#11283: *1 test location: "/456/"
2018/02/12 16:03:51 [debug] 11283#11283: *1 using configuration "=/456/"

=
Запрос в несуществующий локейшен

2018/02/12 16:22:47 [debug] 11285#11285: *3 http request line: "GET 
/7890/ HTTP/1.1"
2018/02/12 16:22:47 [debug] 11285#11285: *3 http uri: "/7890/"

2018/02/12 16:22:47 [debug] 11285#11285: *3 test location: ""
2018/02/12 16:22:47 [debug] 11285#11285: *3 test location: "/456/"
2018/02/12 16:22:47 [debug] 11285#11285: *3 test location: "/7890/"
2018/02/12 16:22:47 [debug] 11285#11285: *3 test location: ~ "(\.html$|\.php$)"
2018/02/12 16:22:47 [debug] 11285#11285: *3 using configuration ""

2018/02/12 16:22:47 [debug] 11285#11285: *3 rewrite phase: 3
2018/02/12 16:22:47 [debug] 11285#11285: *3 http finalize request: 404, 
"/7890/?" a:1, c:1
2018/02/12 16:22:47 [debug] 11285#11285: *3 http special response: 404, 
"/7890/?"
2018/02/12 16:22:47 [debug] 11285#11285: *3 test location: "@err404"
2018/02/12 16:22:47 [debug] 11285#11285: *3 using location: @err404 
"/7890/?"
..
=

Т.е. работает-то оно правильно, но проверки существующих локейшенов почему-то 
всегда начинаюся с "/456/". Не понимаю, чем он такой особенный? Если 
отталкиваться от длины, так самый длинный "/7890/"

Спасибо.

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

Re[2]: Вопрос по access_log

2018-02-09 Thread CoDDoC

Насчет уровня location не проверял, но точно проверено, что 'access_log off' в 
уровне server глушит все access_log уровня http
Думаю, с location будет то же самое


>Пятница,  9 февраля 2018, 16:26 +03:00 от Ruslan Ermilov <r...@nginx.com>:
>
>On Fri, Feb 09, 2018 at 04:11:16PM +0300, Slawa Olhovchenkov wrote:
>> On Fri, Feb 09, 2018 at 04:01:09PM +0300, Maxim Dounin wrote:
>> 
>> > Hello!
>> > 
>> > On Fri, Feb 09, 2018 at 12:38:32PM +0300, CoDDoC wrote:
>> > 
>> > [...]
>> > 
>> > > access_log в нижестоящем контексте отменяет все вышестоящие?
>> > 
>> > Как и все остальные директивы, access_log наследуется с 
>> > предыдущих уровней тогда и только тогда, когда на данном уровне не 
>> > указано директив access_log.
>> 
>> и при этом, кажется, нет возможности просто включать/выключать acceess
>> log, не трогая его настройки?
>
>Запись в лог может быть условной при помощи параметра "if=".
>
>Кроме того, можно на внешнем уровне (напр., server) задать access_log'и,
>а на вложенном уровне (напр., location) указать "access_log off;".
>Тогда на данном вложенном уровне access_log'и будут отключены, а
>на других вложенных уровнях (где не указаны свои access_log'и) будут
>действовать настройки как на внешнем уровне.
>
>Я, впрочем, не уверен, что понял Ваш витиеватый вопрос правильно.
>
>http://nginx.org/r/access_log/ru
>___
>nginx-ru mailing list
>nginx-ru@nginx.org
>http://mailman.nginx.org/mailman/listinfo/nginx-ru


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

Re[2]: Вопрос по access_log

2018-02-09 Thread CoDDoC

Да, спасибо, уже разобрался "методом научного тыка".
ИМХО, неплохо было бы это в доках указать


>Пятница,  9 февраля 2018, 16:01 +03:00 от Maxim Dounin <mdou...@mdounin.ru>:
>
>Hello!
>
>On Fri, Feb 09, 2018 at 12:38:32PM +0300, CoDDoC wrote:
>
>[...]
>
>> access_log в нижестоящем контексте отменяет все вышестоящие?
>
>Как и все остальные директивы, access_log наследуется с 
>предыдущих уровней тогда и только тогда, когда на данном уровне не 
>указано директив access_log.
>
>-- 
>Maxim Dounin
>http://mdounin.ru/
>___
>nginx-ru mailing list
>nginx-ru@nginx.org
>http://mailman.nginx.org/mailman/listinfo/nginx-ru


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

Вопрос по access_log

2018-02-09 Thread CoDDoC

Доброе время суток!
nginx/1.13.8

Случайно обнаружилась непонятка.

Конфиг 1:
http {
    
    log_format f1 '[$time_local - 1]';
    log_format f2 '[$time_local - 2]';

    access_log /var/log/nginx/1.log f1;
    access_log /var/log/nginx/2.log f2;

    server {
    listen ...
    root 
    index .
#    access_log /var/log/nginx/1.log f1;
#    access_log /var/log/nginx/2.log f2;
    }
}

Делаем запрос и получаем ожидаемое: запись в ОБА файла.
---
Теперь так.
Конфиг 2:
http {
    
    log_format f1 '[$time_local - 1]';
    log_format f2 '[$time_local - 2]';

    access_log /var/log/nginx/1.log f1;
#    access_log /var/log/nginx/2.log f2;

    server {
    listen ...
    root 
    index .
#    access_log /var/log/nginx/1.log f1;
    access_log /var/log/nginx/2.log f2;
    }
}

И запись ТОЛЬКО во второй файл.
---
Конфиг 3:
http {
    
    log_format f1 '[$time_local - 1]';
    log_format f2 '[$time_local - 2]';

#    access_log /var/log/nginx/1.log f1;
#    access_log /var/log/nginx/2.log f2;

    server {
    listen ...
    root 
    index .
    access_log /var/log/nginx/1.log f1;
    access_log /var/log/nginx/2.log f2;
    }
}

Опять все ожидаемо, запись в оба файла.
---
В server / location похожая ситуация:
server {
    listen ...
    root ...
    index ...
    
    access_log /var/log/nginx/1.log f1;
    

    # Все, что не совпало с разрешенными
    location "" {
    return 404;
    }

    error_page 404 = @err404;

    location @err404 {
    keepalive_timeout 0;
    rewrite ^ /err/404.html break;
    access_log /var/log/nginx/2.log f2;
    }
}

Ожидаемо: бредовый запрос должен отметиться и в 1.log, и в 2.log
По факту: если работает "access_log /var/log/nginx/2.log f2;", соответственно, 
не работает "access_log /var/log/nginx/1.log f1;"
Правильный запрос приходит в 1.log, бредовый - в 2.log

Если "access_log /var/log/nginx/2.log f2;" отключить, тогда в 1.log приходят 
все запросы, и правильные, и бредовые.

access_log в нижестоящем контексте отменяет все вышестоящие?
--___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Непонятное количество воркеров

2018-01-26 Thread CoDDoC

Доброго времени суток!

nginx/1.13.8

Тестовый сервер, 2 ядра. В конфиге 'worker_processes auto' или 
'worker_processes 2' - без разницы

pstree дает такую картину:

nginx───2*[nginx───32*[{nginx}]]

32 воркера на каждый из двух

Куда копать?
--___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Список модулей

2018-01-08 Thread CoDDoC

Доброе время суток!

nginx -V показывает вкомпиленные модули.
А как, без просмотра конфига, оперативно посмотреть, какие динамические модули 
загружены директивой load_module?
Что-то типа php -m, apachectl -M.

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

Re[2]: Непонятки с ответом 400

2017-11-20 Thread CoDDoC

Ладно, с этим разберусь.
Еще толику Вашего времени... Не совсем в тему, но почти. О выборе секции server 
для обработки запроса.

Я слегка запутался, что от чего зависит: $host от $server_name или наоборот?
Вот как я это понимаю.

1. Сначала неправильный запрос:
echo -e 'HEAD http://www.other-domain.com/some-path 
HTTP/1.1\n''host:www.my-domain.com\n''user-agent:NCAT-TEST\n'| ncat 
www.my-domain.com 80
Как все происходит (ИМХО):
1.1. Получаем значение $host из строки запроса: $host = www.other-domain.com
На заголовок ($http_host = www.my-domain.com) в данном случае не смотрим.
1.2. Ищем секцию, соответствующую значению $host для заданного порта (80)
1.3. Такой секции не существует, запрос передается в дефолтовую, и получаем 
$server_name = _

2. Теперь правильный запрос:
echo -e 'HEAD / HTTP/1.1\n''host:www.my-domain.com\n''user-agent:NCAT-TEST\n'| 
ncat www.my-domain.com 80
2.1. В строке запроса хоста нет, берем из заголовка ($http_host = 
www.my-domain.com).
Получаем значение $host из $http_host: $host= www.my-domain.com
2.2. Ищем секцию, соответствующую значению $host для заданного порта (80)
2.3. Передаем в нее запрос и получаем $server_name = www.my-domain.com

3. Опять неправильный запрос с пустым $http_host:
echo -e 'HEAD / HTTP/1.1\n''host:\n''user-agent:NCAT-TEST\n'| ncat 
www.my-domain.com 80
3.1. Значения $host = '' и $http_host = ''
3.2. Ищем секцию, соответствующую значению $host для заданного порта (80)
3.3. Такой секции не существует, запрос передается в дефолтовую, и получаем 
$server_name = _
3.4. $host получает значение $server_name, т.е. $host = _
Т.е., в отличие от примера 2, не $server_name получаем из $host, а $host из 
$server_name

Я верно понимаю алгоритм?

>Понедельник, 20 ноября 2017, 16:24 +03:00 от Maxim Dounin <mdou...@mdounin.ru>:
>
>Hello!
>
>On Mon, Nov 20, 2017 at 03:43:16PM +0300, CoDDoC wrote:
>
>> Это я понял. Бот дернул запрос и быстро сбежал, чтобы не попасть в бан. 
>> Однако-же попал :)
>> Как мне эмулировать такую ситуацию?
>
>Я, вроде бы, вполне однозначно написал:
>
>> > Если клиент закрыл соединение, не прислав запрос полностью - 
>> > то ...
>
>Так и эмулировать - закрывать соединение, не прислав запрос 
>полностью.
>
>[...]
>
>-- 
>Maxim Dounin
>http://mdounin.ru/
>___
>nginx-ru mailing list
>nginx-ru@nginx.org
>http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

Re[2]: Непонятки с ответом 400

2017-11-20 Thread CoDDoC

Это я понял. Бот дернул запрос и быстро сбежал, чтобы не попасть в бан. 
Однако-же попал :)
Как мне эмулировать такую ситуацию?


>Понедельник, 20 ноября 2017, 15:34 +03:00 от Maxim Dounin <mdou...@mdounin.ru>:
>
>Hello!
>
>On Mon, Nov 20, 2017 at 02:57:13PM +0300, CoDDoC wrote:
>
>> Доброго дня!
>> 
>> Собственно, классическая секция server, принимающая запросы с неправильным 
>> $host:
>> 
>> server {
>>     listen :80 default_server;
>>     listen :443 default_server;
>>     server_name _;
>>     return 444;
>>     access_log  здесь лог, что попадет в эту секцию
>> }
>> 
>> Формат этого лога:
>> [$remote_addr] [$host] [$http_host] [$request] [$status] [$http_user_agent] 
>> [$server_name] [$server_port]
>> 
>> Там такая запись:
>> [155.94.254.143] [] [] [GET /OWA-AUTODISCOVER-EWS 
>> HTTP/1.1] [400] [Mozilla/5.0 Project 25499 (project25499.com)] [_] [80]
>> 
>> В error логе вижу такое:
>> [info] 7455#0: *356814 client prematurely closed connection while reading 
>> client request headers, client: 155.94.254.143, server: _, request: "GET 
>> /OWA-AUTODISCOVER-EWS HTTP/1.1", host: ""
>> 
>> Хорошо, откуда 400, если должно быть 444?
>
>Если клиент закрыл соединение, не прислав запрос полностью - то 
>это ошибка 400 Bad Request.  До обработки запроса - которая 
>вернула бы 444 в соответствии в "return 444" в конфигурации - дело 
>просто не доходит, потому что запрос ещё не получен полностью.
>
>-- 
>Maxim Dounin
>http://mdounin.ru/
>___
>nginx-ru mailing list
>nginx-ru@nginx.org
>http://mailman.nginx.org/mailman/listinfo/nginx-ru


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

Непонятки с ответом 400

2017-11-20 Thread CoDDoC

Доброго дня!

Собственно, классическая секция server, принимающая запросы с неправильным 
$host:

server {
    listen :80 default_server;
    listen :443 default_server;
    server_name _;
    return 444;
    access_log  здесь лог, что попадет в эту секцию
}

Формат этого лога:
[$remote_addr] [$host] [$http_host] [$request] [$status] [$http_user_agent] 
[$server_name] [$server_port]

Там такая запись:
[155.94.254.143] [] [] [GET /OWA-AUTODISCOVER-EWS 
HTTP/1.1] [400] [Mozilla/5.0 Project 25499 (project25499.com)] [_] [80]

В error логе вижу такое:
[info] 7455#0: *356814 client prematurely closed connection while reading 
client request headers, client: 155.94.254.143, server: _, request: "GET 
/OWA-AUTODISCOVER-EWS HTTP/1.1", host: ""

Хорошо, откуда 400, если должно быть 444?
Пытаюсь эмулировать ситуацию:
echo -e 'GET /OWA-AUTODISCOVER-EWS HTTP/1.1\n''host:\n''user-agent:Mozilla/5.0 Project 25499 (project25499.com)\n'| ncat 
 80

И получаю ожидаемое 444. Т.е. за исключением ответа 444 и моего IP, все 
аналогично:
[<мой IP>] [] [] [GET /OWA-AUTODISCOVER-EWS HTTP/1.1] 
[444] [Mozilla/5.0 Project 25499 (project25499.com)] [_] [80]

Вот такая печалька...
Что я упускаю и как получить 400?

Спасибо.

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

Вопрос по дебагу

2017-11-13 Thread CoDDoC


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

Например, что означают такие записи в режиме debug_http:

1. 2017/11/13 07:41:37 [debug] 624#0: *244736 rewrite phase: 3
    2017/11/13 07:41:37 [debug] 624#0: *244736 post rewrite phase: 4
    2017/11/13 07:41:37 [debug] 624#0: *244736 generic phase: 5
    2017/11/13 07:41:37 [debug] 624#0: *244736 generic phase: 6
    2017/11/13 07:41:37 [debug] 624#0: *244736 generic phase: 7
    2017/11/13 07:41:37 [debug] 624#0: *244736 generic phase: 8

    2017/11/13 07:41:37 [debug] 624#0: *244736 http script var: "Q^Y,m"
    2017/11/13 07:41:37 [debug] 624#0: *244736 limit conn: 4B30596F 1
    2017/11/13 07:41:37 [debug] 624#0: *244736 access phase: 9
    2017/11/13 07:41:37 [debug] 624#0: *244736 access phase: 10
    2017/11/13 07:41:37 [debug] 624#0: *244736 post access phase: 11

2. 2017/11/13 07:41:37 [debug] 624#0: *244736 http script copy: "Connection: 
close^M"
    2017/11/13 07:41:37 [debug] 624#0: *244736 http script copy: ""
    2017/11/13 07:41:37 [debug] 624#0: *244736 http script copy: ""
    2017/11/13 07:41:37 [debug] 624#0: *244736 http script copy: ""
    2017/11/13 07:41:37 [debug] 624#0: *244736 http script copy: ""
Последние 4 пустых строки

3. 2017/11/13 07:41:37 [debug] 624#0: *244736 http cleanup add: 01F02220
    2017/11/13 07:41:37 [debug] 624#0: *244736 get rr peer, try: 1
    2017/11/13 07:41:37 [debug] 624#0: *244736 http upstream connect: -2
    2017/11/13 07:41:37 [debug] 624#0: *244736 http finalize request: -4, "/?" 
a:1, c:2
    2017/11/13 07:41:37 [debug] 624#0: *244736 http request count:2 blk:0
    2017/11/13 07:41:37 [debug] 624#0: *244736 http run request: "/?"
    2017/11/13 07:41:37 [debug] 624#0: *244736 http upstream check client, 
write event:1, "/"
    2017/11/13 07:41:37 [debug] 624#0: *244736 http upstream recv(): -1 (11: 
Resource temporarily unavailable)

Здесь особо интересует (11: Resource temporarily unavailable). Запрос делался в 
корень методом HEAD
Потому что дальше, вроде бы, все в порядке:
    2017/11/13 07:41:37 [debug] 624#0: *244736 http upstream request: "/?"
    2017/11/13 07:41:37 [debug] 624#0: *244736 http upstream send request 
handler
    2017/11/13 07:41:37 [debug] 624#0: *244736 http upstream send request
    2017/11/13 07:41:37 [debug] 624#0: *244736 http upstream send request body
    2017/11/13 07:41:37 [debug] 624#0: *244736 http upstream request: "/?"
    2017/11/13 07:41:37 [debug] 624#0: *244736 http upstream process header
    2017/11/13 07:41:37 [debug] 624#0: *244736 http proxy status 200 "200 OK"

4. 2017/11/13 07:41:37 [debug] 624#0: *244736 http write filter: l:1 f:0 s:298
    2017/11/13 07:41:37 [debug] 624#0: *244736 http write filter limit 0
    2017/11/13 07:41:37 [debug] 624#0: *244736 http write filter 

    2017/11/13 07:41:37 [debug] 624#0: *244736 finalize http upstream request: 0
    2017/11/13 07:41:37 [debug] 624#0: *244736 finalize http proxy request
    2017/11/13 07:41:37 [debug] 624#0: *244736 free rr peer 1 0
    2017/11/13 07:41:37 [debug] 624#0: *244736 close http upstream connection: 5
    2017/11/13 07:41:37 [debug] 624#0: *244736 http finalize request: 0, "/?" 
a:1, c:1
    2017/11/13 07:41:37 [debug] 624#0: *244736 set http keepalive handler
    2017/11/13 07:41:37 [debug] 624#0: *244736 http close request

Спасибо.
--___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re[2]: Зацикливание на редиректе

2017-08-07 Thread CoDDoC

А вот интересно, от ботов тоже будем требовать соблюдения RFC?
Я воспроизвел ситуацию, как создать бесполезную нагрузку на сервер при 
бесконечном редиректе.
Правильно я делаю запрос или нет - в данном случае не важно. Важно то, что оно 
работает, и у сервера нет встроенных средств для корректной обработки такой 
ситуации. По большому счету, это называется уязвимостью.
Дальше. господа разрабы, решать вам. Закрыть проблему или оставить все как есть 
и подождать, пока эту уязвимость начнут эксплуатировать.

Засим позволю себе откланяться, поскольку не имею времени продолжать 
бессмысленную дискуссию.
Спасибо.


>Понедельник,  7 августа 2017, 16:12 +03:00 от Валентин Бартенев 
><vb...@nginx.com>:
>
>On Monday 07 August 2017 15:26:11 CoDDoC wrote:
>> Ну, хорошо. Пусть в моем примере вообще нет хоста.
>> Тогда что такое  https://test.com ? Давайте назовем строкой запроса, суть 
>проблемы от этого не меняется.
>
>В вашем примере это аргумент командной строки, который не участвует в запросе.
>В строке запроса он не передается.
>
>
>> В документации так:
>> " $host
>> в порядке приоритета: имя хоста из строки запроса, или имя хоста 
>из поля “Host” заголовка запроса.,"
>> 
>> Объясните мне, пожалуйста, что понимать как "имя хоста из строки запроса" и 
>"имя хоста из поля “Host” заголовка запроса".
>> Желательно с примером для курла, как особо одаренному.
>
>Что такое строка запроса описано в RFC:
>https://tools.ietf.org/html/rfc7230#section-3.1.1
>
>Пример с curl:
>
>$ curl -ILH 'Host:  www.nginx.org ' -x  http://nginx.org:80/ http://nginx.org/
>
>
>> 
>> Далее, Вы приводите пример с netcat. Аналогично можно использовать telnet.
>> Только ведь после получения Location ему нужно следовать. Полученный 
>Location:  http://nginx.org/ куда возвращает? На HEAD  http://nginx.org/
>HTTP/1.1.
>
>Первый пример netcat как раз содержит  http://nginx.org/ в строке запроса
>и как вы можете наблюдать - редиректа нет.
>
>Второй пример не содержит в строке запроса хоста, а в заголовке Host
>содержится  www.nginx.org и происходит редирект.
>
>
>> 
>> То же самое, только не вводить построчно:
>> 
>> curl -ILH 'Host:  www.nginx.org '  https://nginx.org/
>> 
>> И точно такое же зацикливание.
>
>В данном случае отправляет запрос только с  www.nginx.org в заголовке Host
>и отсутствием хоста в строке запроса.  Так работает curl.
>
>Зацикливания происходит только потому, что вы сами заставили curl
>постоянно отправлять запрос с Host:  www.nginx.org , о чем предупреждает
>документация:
>
>
>man curl:
>
>   -H, --header 
>
>  WARNING: headers set with this option will be set in
>  all requests - even after  redirects  are  followed,
>  like when told with -L, --location. This can lead to
>  the header being sent to other hosts than the origi‐
>  nal  host,  so sensitive headers should be used with
>  caution combined with following redirects.
>
>
>
>Если вы укажите заголовок Host так, как это правильно для curl,
>то никаких проблем нет:
>
> curl -IL  https://www.nginx.org/
>
>
>> Пусть мои примеры неверны. Но работают, и приводят к зацикливанию при 
>псевдо-валидном запросе.
>
>Ваши примеры демонстрируют неправильное использование команды curl,
>о чем вас предупреждает документация.
>
>> По большому счету, меня интересует только, как это побороть.
>> 
>
>Использовать curl правильно.
>
>--
>Валентин Бартенев
>___
>nginx-ru mailing list
>nginx-ru@nginx.org
>http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

Re[2]: Зацикливание на редиректе

2017-08-07 Thread CoDDoC

Ну, хорошо. Пусть в моем примере вообще нет хоста.
Тогда что такое  https://test.com ? Давайте назовем строкой запроса, суть 
проблемы от этого не меняется.
В документации так:
" $host
    в порядке приоритета: имя хоста из строки запроса, или имя хоста из 
поля “Host” заголовка запроса.,"

Объясните мне, пожалуйста, что понимать как "имя хоста из строки запроса" и 
"имя хоста из поля “Host” заголовка запроса".
Желательно с примером для курла, как особо одаренному.

Далее, Вы приводите пример с netcat. Аналогично можно использовать telnet.
Только ведь после получения Location ему нужно следовать. Полученный Location:  
http://nginx.org/ куда возвращает? На HEAD  http://nginx.org/ HTTP/1.1.

То же самое, только не вводить построчно:

curl -ILH 'Host: www.nginx.org'  https://nginx.org/  

И точно такое же зацикливание.
Пусть мои примеры неверны. Но работают, и приводят к зацикливанию при 
псевдо-валидном запросе.
По большому счету, меня интересует только, как это побороть.

>Понедельник,  7 августа 2017, 13:37 +03:00 от Валентин Бартенев 
><vb...@nginx.com>:
>
>On Monday 07 August 2017 13:25:32 Валентин Бартенев wrote:
>> On Monday 07 August 2017 09:01:39 CoDDoC wrote:
>> > 
>> > Спасибо.
>> > 
>> > Только Вы говорите об URI "/", а вопрос был об URL, точнее - о 
>> > зацикливании, связанном с неправильной (ИМХО) интерпретацией в ngx 
>> > переменной $host. Как она ДОЛЖНА обрабатываться - сказано в доке, что 
>> > имеем ПО ФАКТУ - в моем примере.
>> 
>> Ещё раз.  Вы неправильно интерпретируете команду curl, отсюда и считаете,
>> что поведение nginx отличается от описанного в документации.  Ваш пример
>> неверен.
>> 
>> И далее на этом неверном предположении строите все остальные выводы.
>> 
>> Вы пишите:
>> 
>> | Вот такой случай:
>> | curl -ILH 'Host:  www.test.com '  https://test.com
>> |
>> | Если бы переменная $host получила значение в порядке приоритета, оно было 
>> бы test.com (имя хоста из строки запроса).
>> 
>> Нет не было бы.  Потому что в строке запроса, которую отправляет данная
>> команда curl нет "test.com".  Там нет вообще хоста.
>> 
>[..]
>
>
>Вот наглядный пример, всё работает как описано
>в документации и должно быть по RFC:
>
>
>% netcat nginx.org 80
>HEAD  http://nginx.org/ HTTP/1.1
>Host:  www.nginx.org
>
>HTTP/1.1 200 OK
>Server: nginx/1.13.3
>Date: Mon, 07 Aug 2017 10:34:37 GMT
>Content-Type: text/html; charset=utf-8
>Content-Length: 6680
>Last-Modified: Tue, 11 Jul 2017 15:45:07 GMT
>Connection: keep-alive
>Keep-Alive: timeout=15
>ETag: "5964f283-1a18"
>Accept-Ranges: bytes
>
>HEAD / HTTP/1.1
>Host:  www.nginx.org
>
>HTTP/1.1 301 Moved Permanently
>Server: nginx/1.13.3
>Date: Mon, 07 Aug 2017 10:34:53 GMT
>Content-Type: text/html
>Content-Length: 185
>Connection: keep-alive
>Keep-Alive: timeout=15
>Location:  http://nginx.org/
>
>___
>nginx-ru mailing list
>nginx-ru@nginx.org
>http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

Re[2]: Зацикливание на редиректе

2017-08-07 Thread CoDDoC

Спасибо.

Только Вы говорите об URI "/", а вопрос был об URL, точнее - о зацикливании, 
связанном с неправильной (ИМХО) интерпретацией в ngx переменной $host. Как она 
ДОЛЖНА обрабатываться - сказано в доке, что имеем ПО ФАКТУ - в моем примере.
Добавление опции -v, по сути, ничего не меняет. Разве что лишний раз убедиться, 
что при редиректе передается заголовок HOST.

Тема уже поднималась, в частности, здесь (  
http://mailman.nginx.org/pipermail/nginx-ru/2014-June/054083.html ) довольно 
обширная дискуссия. Но там все достаточно просто, речь идет о явно невалидных 
запросах, которые можно и нужно фильтровать. Я же несколько усложнил задачу и 
привел пример псевдо-валидного запроса, который отфильтровать невозможно.
И до тех пор, пока проблема с переменной $host не будет решена, такое 
зацикливание неизбежно.
Так что вопрос больше к разработчикам.

>Суббота,  5 августа 2017, 21:46 +03:00 от Валентин Бартенев < vb...@nginx.com 
>>:
>
>On Thursday 03 August 2017 12:15:16 CoDDoC wrote:
>[..]
>> Судя по логам, это не совсем так.
>> По крайней мере, в моем случае (nginx/1.10.2), переменная $host получает имя 
>> хоста из строки запроса только если не указано поле host заголовка. Т.е. 
>> обрабатывается ситуация с HTTP/1.0, без $http_host в заголовке. Но если в 
>> заголовке задать какое-то (любое) значение $http_host, это же значение 
>> получает и $host.
>> 
>> Далее ( http://nginx.org/ru/docs/http/request_processing.html ): nginx 
>> "сопоставляет значение поля Host заголовка запроса с директивами server_name 
>> в блоках server, которые соответствуют IP-адресу и порту". Т.е. все-таки 
>> $http_host. А туда можно прописать что угодно.
>> Я не рассматриваю сейчас ситуацию, когда в $http_host прописано имя, не 
>> совпадающее с перечисленными в server_name. Это все благополучно фильтруется 
>> и отправляется на 444. Также, я не рассматриваю браузеры, которые отправляют 
>> правильный $http_host и получают правильные редиректы.
>> 
>> Вот такой случай:
>> curl -ILH 'Host:  www.test.com '  https://test.com
>> 
>> Если бы переменная $host получила значение в порядке приоритета, оно было бы 
>> test.com (имя хоста из строки запроса). Тогда можно было бы реализовать 
>> такой костыль, как фильтрация по условию "$host не равно $http_host". Но в 
>> запросе присутствует заголовок host, и обе переменные $host и $http_host 
>> получают одно и то же значение  www.test.com , отфильтровать невозможно.
>
>
>
>Вы видимо ошибочно считаете, что данная команда curl в качестве строки запроса
>передает " https://test.com ".
>
>Нет, curl в данном случае в строке запроса передает "/".
>
>Чтобы увидеть, что конкретно посылает curl на сервер, можно добавить опцию 
>"-v".
>
>--
>Валентин Бартенев
>___
>nginx-ru mailing list
>nginx-ru@nginx.org
>http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

Зацикливание на редиректе

2017-08-03 Thread CoDDoC

Доброго дня сообществу! Прошу совета по проблеме.
Собственно, редирект с www на https без-www

server {
#1 http to https without www
listen 1.2.3.4:80;
server_name www.test.com test.com;
rewrite ^ https://test.com$request_uri? permanent;
}

server {
#2 https with www to https without www
listen 1.2.3.4:443 ssl;
server_name www.test.com;
rewrite ^ https://test.com$request_uri? permanent;
}

server {
#3 https without www
listen 1.2.3.4:443 ssl;
server_name test.com;
...
}

Насколько я понял из документации
(http://nginx.org/ru/docs/http/ngx_http_core_module.html#var_host), переменная
$host принимает значения "в порядке приоритета: имя хоста из строки запроса,
или имя хоста из поля Host заголовка запроса, или имя сервера, соответствующего
запросу"

Судя по логам, это не совсем так.
По крайней мере, в моем случае (nginx/1.10.2), переменная $host получает имя
хоста из строки запроса только если не указано поле host заголовка. Т.е.
обрабатывается ситуация с HTTP/1.0, без $http_host в заголовке. Но если в
заголовке задать какое-то (любое) значение $http_host, это же значение получает
и $host.

Далее (http://nginx.org/ru/docs/http/request_processing.html): nginx
"сопоставляет значение поля Host заголовка запроса с директивами server_name в
блоках server, которые соответствуют IP-адресу и порту". Т.е. все-таки
$http_host. А туда можно прописать что угодно.
Я не рассматриваю сейчас ситуацию, когда в $http_host прописано имя, не
совпадающее с перечисленными в server_name. Это все благополучно фильтруется и
отправляется на 444. Также, я не рассматриваю браузеры, которые отправляют
правильный $http_host и получают правильные редиректы.

Вот такой случай:
curl -ILH 'Host: www.test.com' https://test.com

Если бы переменная $host получила значение в порядке приоритета, оно было бы
test.com (имя хоста из строки запроса). Тогда можно было бы реализовать такой
костыль, как фильтрация по условию "$host не равно $http_host". Но в запросе
присутствует заголовок host, и обе переменные $host и $http_host получают одно
и то же значение www.test.com , отфильтровать невозможно.
Имя www.test.com перечислено в server_name, в итоге такой запрос успешно
проходит фильтрацию. После сопоставления значения $http_host с server_name,
nginx отправляет запрос в секцию 2, откуда возвращается 301 и новый location
https://test.com , т.е. на выходе получаем тот же самый запрос (curl -ILH
'Host: www.test.com' https://test.com) и, естесвенно, зацикливание на второй
секции:

curl -ILH 'Host: www.test.com' https://test.com
HTTP/1.1 301 Moved Permanently
..
Location: https://test.com/

HTTP/1.1 301 Moved Permanently
..
Location: https://test.com/

Это баг или фича? Или я что-то делаю не так? Как это побороть?
Спасибо.
--___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Непонятки с binary_remote_addr

Upstream и заголовок Host

Вопрос о балансировке нагрузки.

Re[2]: Странная ситуация с levels

Странная ситуация с levels

Re[6]: Запуск php скриптов из разных директории

Re[4]: Запуск php скриптов из разных директории

Re[2]: Запуск php скриптов из разных директории

Re: Запуск php скриптов из разных директории

Re[2]: О заголовке content-type

О заголовке content-type

Re[6]: nginx restart AND listen ip:port

Re[4]: nginx restart AND listen ip:port

Re[2]: nginx restart AND listen ip:port

Re[2]: В каком порядке обрабатываются location?

Re[2]: В каком порядке обрабатываются location?

В каком порядке обрабатываются location?

Re[2]: Вопрос по access_log

Re[2]: Вопрос по access_log

Вопрос по access_log

Непонятное количество воркеров

Список модулей

Re[2]: Непонятки с ответом 400

Re[2]: Непонятки с ответом 400

Непонятки с ответом 400

Вопрос по дебагу

Re[2]: Зацикливание на редиректе

Re[2]: Зацикливание на редиректе

Re[2]: Зацикливание на редиректе

Зацикливание на редиректе

30 matches

Site Navigation

Mail list logo

Footer information