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

Andrey Istochkin alstpostbox at gmail.com
Mon Jun 29 09:09:58 UTC 2015


Дело в том, что 'destination' передается в заголовках запроса, для правки
которых встроенных средств, наверное, нет. Можно попробовать посмотреть в
сторону http://wiki.nginx.org/HttpHeadersMoreModule или как-то поизголяться
с проксированием на самого себя и выставлением в проксированном запросе
нужного заголовка. Но как-то это костыльно все очень.

29 июня 2015 г., 11:51 пользователь Иван Мишин <simplebox66 at gmail.com>
написал:

> Не ужели нет никаких вариантов дописать слеш в конец того каталога в
> который перемещается другой каталог?
>
> 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
>>>
>>
>>
>
> _______________________________________________
> 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/0d7294a9/attachment.html>


Подробная информация о списке рассылки nginx-ru