Re: Re[2]: проблема с rewrite

[Иван Мишин]

Не ужели нет никаких вариантов дописать слеш в конец того каталога в
который перемещается другой каталог?

25 июня 2015 г., 14:54 пользователь Иван Мишин <simplebox66 at 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 <
> alstpostbox at 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 пользователь Иван Мишин <simplebox66 at 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 <onokonem at gmail.com>
>>> написал:
>>>
>>> > Даниель, можно подробнее пожалуйста про этот момент
>>>> про какой? про переход в именованный локейшн? или про то, что код,
>>>> который для этого используется, наружу отдаваться не должен?
>>>> _______________________________________________
>>>> nginx-ru mailing list
>>>> nginx-ru at nginx.org
>>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>>>
>>>
>>>
>>> _______________________________________________
>>> nginx-ru mailing list
>>> nginx-ru at nginx.org
>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>>
>>
>>
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150629/6a999933/attachment-0001.html>