> > Дело в том, что 'destination' передается в заголовках запроса, для правки > которых встроенных средств, наверное, нет
Да только судя по tcpdump destination то правильный , вот кусочек из дампа: 192.168.200.81.50818 > 192.168.200.92.80: Flags [P.], cksum 0xd386 (correct), seq 1:226, ack 1, win 2053, length 225 E.. |~@...ko...Q...\...P_.G9....P.......MOVE /Family/aa11 HTTP/1.1 Connection: Keep-Alive User-Agent: Microsoft-WebDAV-MiniRedir/6.3.9600 Destination: http://192.168.200.92/Family/bb22/aa11 Overwrite: F translate: f Content-Length: 0 Host: 192.168.200.92 29 июня 2015 г., 12:09 пользователь Andrey Istochkin <alstpost...@gmail.com> написал: > Дело в том, что 'destination' передается в заголовках запроса, для правки > которых встроенных средств, наверное, нет. Можно попробовать посмотреть в > сторону http://wiki.nginx.org/HttpHeadersMoreModule или как-то > поизголяться с проксированием на самого себя и выставлением в > проксированном запросе нужного заголовка. Но как-то это костыльно все очень. > > 29 июня 2015 г., 11:51 пользователь Иван Мишин <simplebo...@gmail.com> > написал: > > Не ужели нет никаких вариантов дописать слеш в конец того каталога в >> который перемещается другой каталог? >> >> 25 июня 2015 г., 14:54 пользователь Иван Мишин <simplebo...@gmail.com> >> написал: >> >> Андрей, спасибо, помогло. Добавил break и каталоги удаляются без проблем. >>> Но есть еще один вопрос, касающийся метода MOVE, то есть перемещение >>> каталогов. >>> >>> К письму прикрепляю логи. >>> Проблема конкретно тут: >>> 2015/07/26 14:48:08 [error] 6735#0: *61 both URI "/Family/Новая папка/" >>> and "Destination" URI " >>> http://192.168.200.92/Family/%D0%9D%D0%BE%D0%B2%D0%B0%D1%8F%20%D0%BF%D0%B0%D0%BF%D0%BA%D0%B0%20%282%29/%D0%9D%D0%BE%D0%B2%D0%B0%D1%8F%20%D0%BF%D0%B0%D0%BF%D0%BA%D0%B0" >>> should be either collections or non-collections, client: 192.168.200.81, >>> server: 192.168.200.92, request: "MOVE >>> /Family/%D0%9D%D0%BE%D0%B2%D0%B0%D1%8F%20%D0%BF%D0%B0%D0%BF%D0%BA%D0%B0 >>> HTTP/1.1", host: "192.168.200.92" >>> >>> Винда не понимает сама где каталоги, а где просто файлы. >>> То есть в случае метода MOVE я с помощью rewrite дописываю в конце слеш, >>> а вот как дописать слеш к тому каталогу в который я перемещаю первый >>> каталог не понятно. Если к методу PROPFIND дописать >>> if (-d $webdav_root/$uri) { >>> rewrite ^(.*[^/])$ $1/ break; >>> } >>> то в логах просто все зацикливается и все. Может у вас есть какие-то >>> мысля по этому поводу? >>> >>> 25 июня 2015 г., 11:49 пользователь Andrey Istochkin < >>> alstpost...@gmail.com> написал: >>> >>> Попробуйте в @delete_handler в rewrite добавить 'break'. Так как в >>>> access_логе фигурирует 598, то похоже на то, что @delete_handler >>>> отрабатывает, отрабатывает rewrite, после чего запрос уходит снова в >>>> 'location ^~ /Family', опять отрабатывает 'return 598', но так как >>>> recursive_error_pages по-умолчанию выключена, error_page на этот раз не >>>> срабатывает, и клиент получает 598. >>>> >>>> 25 июня 2015 г., 9:28 пользователь Иван Мишин <simplebo...@gmail.com> >>>> написал: >>>> >>>> в этом случае до винды этот код дойти не должен. если доходит - вы >>>>>> плохо настроили error >>>>> >>>>> >>>>> Ну судя по tcpdump на стороне винды, 598 код все же доходит до нее. >>>>> >>>>> про какой? про переход в именованный локейшн? или про то, что код, >>>>>> который для этого используется, наружу отдаваться не должен? >>>>> >>>>> >>>>> И про то и про другое, если не затруднит. >>>>> ВО-первых, PROPFIND метод работает, при том что он организован в моем >>>>> конфиге тем же способом что и метод DELETE с той лишь разницей что >>>>> PROPFIND >>>>> через 599 код работает, а DELETE через 598. Но я так понимаю что-это >>>>> различие не на что не влияет ибо пробовал менять коды местами и...вот >>>>> цитата моих слов по этому поводу: >>>>> >>>>>> 599 отрабатывает точно правильно потому что метод PROPFIND работает >>>>>> без вопросов. В качестве экспиремента поменял местами 599 и 598 в >>>>>> итоге PROPFIND как работал так и работает а DELETE каталогов как не >>>>>> работал >>>>>> так и не работает. >>>>> >>>>> >>>>> ВО-вторых, мне казалось что если с клиента ( в данном случае с винды) >>>>> ушел запрос DELETE на nginx и nginx то nginx его должен отработать и >>>>> каталог удалить, и не важно что он ответит клиент, потому что для клиента >>>>> этот ответ будет чисто информационным т.е. не будет влиять на результат >>>>> выполнения первого запроса (запроса на DELETE). >>>>> >>>>> >>>>> 24 июня 2015 г., 18:55 пользователь Daniel Podolsky < >>>>> onoko...@gmail.com> написал: >>>>> >>>>> > Даниель, можно подробнее пожалуйста про этот момент >>>>>> про какой? про переход в именованный локейшн? или про то, что код, >>>>>> который для этого используется, наружу отдаваться не должен? >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >> > > > _______________________________________________ > 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