Re: PUT access_by_lua_file
В письме от Пт, 17 апреля 2015 02:07:33 пользователь itcod написал: Илья добрый день! вы сами клиенту сказали, что поддерживаете PUT, он делает PUT, вы его фейлите. прикиньте, как клиент расстраивается от такого расклада )) Это спорный вопрос расстраивается или просто некоректна логика обработки ответов от сервера в данной точке программы клиента:) Если бы nginx сразу на PUT ответил 405 (Method Not Allowed), то все некорректности по обработке кода ответа можно было бы свалить на клиента, и оповестить их разработчика. Дело в том, что, на сколько я понил проблему при описании с ваших слов, со стороны NginX всё корректно. На PUT он отвечает нельзя сразу по получении (т.е. по окончании) *запроса*. А отвечать нельзя по получении одного лишь заголовка, не дожидаясь тела — неправильно. -- Best regards, mva signature.asc Description: This is a digitally signed message part. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: PUT access_by_lua_file
PS: У меня дежавю. прецедент вспомнился подобная тема обсуждалась в годах 1995 в fido-конференции по ifcico. Актуальность подобных холостых передач там была очень высокая, из за ограниченного кол-ва каналов передачи, их низких скоростей и высокой стоимости.. как результат реализовали обрыв подобных сессий для предотвращения излишних затрат и освобождения линий. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258069,258137#msg-258137 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: PUT access_by_lua_file
Илья добрый день! вы сами клиенту сказали, что поддерживаете PUT, он делает PUT, вы его фейлите. прикиньте, как клиент расстраивается от такого расклада )) Это спорный вопрос расстраивается или просто некоректна логика обработки ответов от сервера в данной точке программы клиента:) Если бы nginx сразу на PUT ответил 405 (Method Not Allowed), то все некорректности по обработке кода ответа можно было бы свалить на клиента, и оповестить их разработчика. В данном случае я вижу выше этой ошибки BitKinex по обработке кодов, некорректную с моей точки зрения обработку команды PUT у nginx. И именно по ней я пытаюсь выяснить жук это или фича такая. Если жук - то понятно, что проясняем сознание и в очередь на лечение. Если фича - то хотелось бы понять, в чём прелесть перевешивающая недостатки. Запросы методом OPTIONS при PUT: BitKinex - не использует FAR-NetDrive - использует Даже тут чехарда. Да я буду пытаться сказать клиентам, что использовать можно, а что нельзя... Только это imho косметический костыль. Так как тот кто специально решит проигнорировать рекомендации сервера (я имею в виду если кому захочется положить сервер), он всегда сможет выполнить, то что я обнаружил. А это imho с точки зрения надёжности nginx большой минус. Да и я сам делая самописный WebDAV клиент ориентировался бы больше на обаботку ответов и уже во втором эшелоне на рекомендации сервера. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258069,258134#msg-258134 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: PUT access_by_lua_file
mva добрый день! На PUT он отвечает нельзя сразу по получении (т.е. по окончании) *запроса*. Да. вы описываете ситуацию верно... как я её вижу. 1. получение nginx'ом заголовка сообщения 2. получение тела сообщения [... lua ...] - 405 А отвечать нельзя по получении одного лишь заголовка, не дожидаясь тела — неправильно. Если не затруднит обоснуйте плиззз свою точку зрения. Моя такова: Если метод запрещён внутри (и не важно знает об этом клиент или нет), то можно и даже нужно обрывать соединение и вернуть код 405!. Зачем нам получать огромное тело сообщения, если мы не обрабатываем этот метод и не будем обрабатывать тело. Пример: Инициирую 1000-1 сессий, игнорирую рекомендации nginx в OPTION и Origin, и каждая сессия инициирует PUT video.mp4 размером скажем 4G. С большой долей вероятности положу атакуемый сервер. А даже если не положу, то заспамлю и загружу холостой работой. Следовательно при обработке PUT если сервер оборвал получение и вернул код ошибки 405 то передавать тело клиенту уже не предоставляется возможности. imho это логично и устраняет описанную в первом сообщении проблему. И отсуда вытекает вопрос к разработчикам о внутренностях nginx. существует ли возможность реализовать запуск выполнения авторизатора на lua между двумя этапами обработки. 1. получение nginx'ом заголовка сообщения [... lua ...] -405 2. УЖЕ НЕ! получаем тела сообщения Или существуют ещё какие либо более простые методы решения. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258069,258136#msg-258136 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: PUT access_by_lua_file
В письме от Пт, 17 апреля 2015 08:36:39 пользователь itcod написал: Нескромный вопрос так и оставим существовать эту PUT дырку? пока кого нибудь не заклюеет жареный петух Ну, у меня на сервере с отключенным PUT, например, 405+400 выбрасывается сразу, не получая содержимое файла. Другое же дело, когда метод фигурирует в разрешённых у сервера на более низком уровне (module_http_dav) и рулится уже в access-модуле (да ещё и в ngx_lua, что ещё дальше) ;) Т.е. ситуация такая: DAV-модуль говорит серверу, что он готов получать и обрабатывать PUT. Сервер, следовательно, считает PUT валидным запросом. Следовательно, когда приходит PUT — он получает запрос целиком (до этого момента он валиден) и только потом, получив запрос, целиком отдаёт его дальше по цепочке в модули. Поэтому в руках ngx_lua (в access-директиве) оказывается запрос целиком. Да и в обычном, емнип, access-модуле, тоже обработка происходит ПОСЛЕ получения запроса, а не на этапе заголовков :) -- Best regards, mva signature.asc Description: This is a digitally signed message part. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: PUT access_by_lua_file
mva добрый день ещё раз:) Ну, у меня на сервере с отключенным PUT, например, 405+400 выбрасывается сразу, не получая содержимое файла. А у вас это в динамике или статично прописана блокировка? если динамично поделитесь идеей плиззз... Другое же дело, когда метод фигурирует в разрешённых у сервера на более низком уровне (module_http_dav) Я пытался решить задачку на этом уровне... мня предложили порешать её в этой точке :))) http://forum.nginx.org/read.php?21,258024,258045#msg-258045 и рулится уже в access-модуле (да ещё и в ngx_lua, что ещё дальше) ;) А куда деваться я пробовал решить её на иных уровнях... а там переменные конфг не поддерживает и потому динамику не организовать Т.е. ситуация такая: DAV-модуль говорит серверу, что он готов получать и обрабатывать PUT. Сервер, следовательно, считает PUT валидным запросом. mva можно подробнее!!! Вы хотите сказать, что если я в хидерах укажу что PUT запрещён - то nginx откажется принимать тело если поймает на входе PUT? И это произойдёт вне зависимости, будет клиент послушным мальчиком, или будет пихать пальцы во все дырки... не обращая вниание на анонсы nginx??? ВЫ В ЭТОМ УВЕРЕНЫ? Разработчика бы услышать. по этому вопросу правда ли блокирнёт или опять день на тесты выкидывать чтобы понять текущую логику поведения. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258069,258151#msg-258151 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: PUT access_by_lua_file
ЗЫ Т.е. ситуация такая: DAV-модуль говорит серверу, что он готов получать и обрабатывать PUT. Сервер, следовательно, считает PUT валидным запросом. а ваш коментарий про OPTIONS и PUT а если я из lua попытаюсь изменить OPTIONS то PUT для DAV-модуля будет инвалидным. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258069,258152#msg-258152 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: PUT access_by_lua_file
если клиент говорит Expect: 100-Continue, то в этом случае вы можете ему сказать 405 сразу (или ответить 100-м кодом). без этого хедера - да, ответить можно, только получив запрос полностью 17 апреля 2015 г., 11:13 пользователь Vadim A. Misbakh-Soloviov m...@mva.name написал: В письме от Пт, 17 апреля 2015 02:07:33 пользователь itcod написал: Илья добрый день! вы сами клиенту сказали, что поддерживаете PUT, он делает PUT, вы его фейлите. прикиньте, как клиент расстраивается от такого расклада )) Это спорный вопрос расстраивается или просто некоректна логика обработки ответов от сервера в данной точке программы клиента:) Если бы nginx сразу на PUT ответил 405 (Method Not Allowed), то все некорректности по обработке кода ответа можно было бы свалить на клиента, и оповестить их разработчика. Дело в том, что, на сколько я понил проблему при описании с ваших слов, со стороны NginX всё корректно. На PUT он отвечает нельзя сразу по получении (т.е. по окончании) *запроса*. А отвечать нельзя по получении одного лишь заголовка, не дожидаясь тела — неправильно. -- Best regards, mva ___ 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: PUT access_by_lua_file
А вы, всё-таки, ответьте, пожалуйста, на вопрос, почему вы не хотите убрать PUT из OPTIONS? ;) -- Best regards, mva signature.asc Description: This is a digitally signed message part. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: PUT access_by_lua_file
добавил в location конструкцию
if ($request_method = PUT) {
return 403;
}
по прежнему PUT прокачивает холостые гигобайты трафика! :(
Буду рад мыслям сообщества!
какими ещё существующими средствами nginx, можно всё таки прекратить такое
сверхлояльное поведение nginx с настырными PUT'анами:)))
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,258069,258163#msg-258163
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: PUT access_by_lua_file
хотите совет? поставьте CEPH в качестве упражнения, ваши манипуляции с DAV выглядят вполне симпатично. для продакшена распределенный кластер CEPH/S3 (по сути тот же http-доступ) более крут. клиентов S3 не меньше, чем DAV документации полно, она хорошего качества, http://habrahabr.ru/company/performix/blog/218065/ 17 апреля 2015 г., 17:36 пользователь itcod nginx-fo...@nginx.us написал: Илья добрый день. если клиент говорит Expect: 100-Continue, то в этом случае вы можете ему сказать 405 сразу (или ответить 100-м кодом). Спасибо Илья. Понял принцип. без этого хедера - да, ответить можно, только получив запрос полностью Нескромный вопрос так и оставим существовать эту PUT дырку? пока кого нибудь не заклюеет жареный петух Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258069,258148#msg-258148 ___ 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: PUT access_by_lua_file
Упростил схему.
1. из dav_methods изъял PUT
2. отключил луа авторизатор
тестил BitKinex'ом
Результат: метод PUT не блокирует nginx, хотя он запрещён в модуле DAV.
то есть всё как было. сначало принимаем большой файл, а потом говорим, что
нам этого нельзя.
server {
listen 80;
server_name dav.example.com;
server_name_in_redirect off;
access_log /var/log/nginx/dav-access.log main;
location / {
access_by_lua_file /etc/nginx/lua/auth-dav1.lua;
dav_methods DELETE COPY MOVE;
dav_ext_methods PROPFIND OPTIONS;
create_full_put_path on;
dav_access user:rw group:rw;
client_body_temp_path /opt/itcod-dav.tmp/;
client_max_body_size 0;
autoindex on;
root /opt/home/;
}
location ~/\.ht {
deny all;
}
}
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,258069,258162#msg-258162
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: PUT access_by_lua_file
Yesterday Apr 17, 2015 at 11:12 itcod wrote: Resolving host name dav.example.com ... Connecting ( home.itcod.com = ip: 10.1.1.1, port: 80 ) Connected (10.1.1.1:80) PROPFIND / HTTP/1.1 Host: home.itcod.com HTTP/1.1 207 Multi-Status Server: nginx/0.8.54 Заметил древнюю версию и сделал аналогичный запрос, а в теле ответа другая: centerh1401 Authorization Required/h1/center hrcenternginx/1.7.11/center У Вас один nginx за другим nginx? Если да, то первый полностью принимает запрос и лишь после этого отправляет его второму, а тот возвращает 405. -- WNGS-RIPE ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: PUT access_by_lua_file
Добрый день Александр! Да там получается пара друг за дугом. Фронт старичёк Ура!!! Вы совершенно правы!!! Обратился BitKinex к внутреннему Он обрывает PUT сразу!!! PUT /IMG_20150414_184225.jpg HTTP/1.1 Host: home.virtual.ko:7070 User-Agent: BitKinex/3.2.3 Accept: */* Pragma: no-cache Cache-Control: no-cache Content-Length: 696983 Content-Type: application/octet-stream Translate: f Authorization: Basic блаблабла== HTTP/1.1 405 Not Allowed Server: nginx/1.7.11 Date: Sat, 18 Apr 2015 05:25:34 GMT Content-Type: text/html Content-Length: 173 Connection: keep-alive Connection closed Спасибо огромное Надо покурить эту инфу... Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258069,258178#msg-258178 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: PUT access_by_lua_file
и на эту ситуацию ещё накладывается дефолтное поведение BitKinex автоматически повторять посылку файла при неудаче... а любой код возврата от PUT кроме успеха он считает неудачей, и многократно повторяет передачу ну и передача в 600к при таком поведении превращается в 18мегов, 30 лишних сессий и в 30 раз больше времени... Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258069,258070#msg-258070 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: PUT access_by_lua_file
еще можно попробовать реализовать запрет PUT таким образом, что в ответе на OPTIONS не показывать PUT 16 апреля 2015 г., 13:51 пользователь itcod nginx-fo...@nginx.us написал: и на эту ситуацию ещё накладывается дефолтное поведение BitKinex автоматически повторять посылку файла при неудаче... а любой код возврата от PUT кроме успеха он считает неудачей, и многократно повторяет передачу ну и передача в 600к при таком поведении превращается в 18мегов, 30 лишних сессий и в 30 раз больше времени... Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258069,258070#msg-258070 ___ 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: PUT access_by_lua_file
чтобы ответить до начала передачи файла, надо реализовать Expect: 100-Continue
16 апреля 2015 г., 13:27 пользователь itcod nginx-fo...@nginx.us написал:
Здравствуйте уважаемые!
Наблюдаю странное поведение nginx.
В тестовом авторизационном файле луа сказано, что метод PUT запрещён (см
листинг ниже).
И при этом когда захожу вижу, что сначало nginx разрешает PUT и идет
передача файла на WEBDAV и только после завершения передачи файла nginx
стартует access_by_lua_file /etc/nginx/lua/auth-dav1.lua и возвращает запрет
PUT(передачи файла)... см лог ниже.
По факту получается, что я не могу запретить из луа-авторизатора передачу
файла? конечно его размещение запрещается... но при этом он качается на
сервер и излишне грузит nginx и канал!!!
Почему так? Это баг, фича, я глючу или ещё чвото?
лог файл BitKinex (кстати FAR-NetDrive ведёт себя анналогично)
Resolving host name dav.example.com ...
Connecting ( dav.example.com = ip: 10.0.0.1, port: 80 )
Connected (10.0.0.1:80)
PUT /IMG_20150414_184225.jpg HTTP/1.1
Host: dav.example.com
User-Agent: BitKinex/3.2.3
Accept: */*
Pragma: no-cache
Cache-Control: no-cache
Content-Length: 696983
Content-Type: application/octet-stream
Translate: f
HTTP/1.1 405 Not Allowed
Server: nginx/0.8.54
Date: Thu, 16 Apr 2015 08:08:52 GMT
Content-Type: text/html
Connection: keep-alive
Content-Length: 173
Connection closed
-
Конфиг virt
dav.conf
server {
listen 80;
server_name dav.example.com;
server_name_in_redirect off;
access_log /var/log/nginx/dav-access.log main;
resolver 10.255.255.1 [::1]:5353;
set $dir /opt/home;
set $dir_path $dir;
if ($uri ~* ^(.*)([$/].*)$) {
set $dir_path $dir$1;
}
set $home $dir_path;
set $sadm_passwd .htpsw;
set $user_passwd .uhtpasswd;
location / {
access_by_lua_file /etc/nginx/lua/auth-dav1.lua;
dav_methods PUT DELETE MKCOL COPY MOVE;
dav_ext_methods PROPFIND OPTIONS;
create_full_put_path on;
dav_access user:rw group:rw;
client_body_temp_path /opt/itcod-dav.tmp/;
client_max_body_size 0;
autoindex on;
root /opt/home/;
}
location ~/\.ht {
deny all;
}
}
---
тестовый листинг луа
auth-dav1.lua
if ngx.var.request_method == 'PUT' then
ngx.exit(405)
end
PS: так же пробовал ngx.exit(403) ngx.exit(423) - результат не меняется.
сначало грузит потом запрещает.
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,258069,258069#msg-258069
___
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: PUT access_by_lua_file
Илья добрый вечер! чтобы ответить до начала передачи файла, надо реализовать Expect: 100-Continue Как я понимаю это же запрос от клиента о возможностях сервера и ответ сервера о том что можно... но это ведь как я понимаю инициируется от клиента. Но есть большая вероятность что не все клиенты этого умеют и многие самопалы и не будут уметь так как это не является обязательным Или реализуем хакатаку чтобы просто загрузить сайт лишними телодвижениями сейчас это вполне реально... и получаем что вариант Expect: 100-Continue возможен только в сети идеальных законопослушников: зы: заранее сорри - может я чегото не правильно понимаю про Expect-Continue - ни разу ещё не реализовывал эту схему взаимодействия. обходился просто разрешениями методов в орижине... но тот вариант тоже не фонтан так как имеет ту же проблему - обработает клиент или проигнорит. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258069,258119#msg-258119 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: PUT access_by_lua_file
вы сами клиенту сказали, что поддерживаете PUT, он делает PUT, вы его фейлите. прикиньте, как клиент расстраивается от такого расклада )) 16 апреля 2015 г., 23:47 пользователь itcod nginx-fo...@nginx.us написал: Илья добрый день! еще можно попробовать реализовать запрет PUT таким образом, что в ответе на OPTIONS не показывать PUT А тут мы упираемся в корректность реализации клиента WEBDAV о которой нам ничего не известно... не особо хочется наслово полагаться на соответствие всех возможных webdav клиентов букве стандарта Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258069,258118#msg-258118 ___ 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: PUT access_by_lua_file
Илья добрый день! еще можно попробовать реализовать запрет PUT таким образом, что в ответе на OPTIONS не показывать PUT А тут мы упираемся в корректность реализации клиента WEBDAV о которой нам ничего не известно... не особо хочется наслово полагаться на соответствие всех возможных webdav клиентов букве стандарта Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258069,258118#msg-258118 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
