Re: Re[2]: проблема с rewrite
Иван Мишин
simplebox66 at gmail.com
Tue Jun 30 13:29:30 UTC 2015
>
> Дело в том, что 'destination' передается в заголовках запроса, для правки
> которых встроенных средств, наверное, нет. Можно попробовать посмотреть в
> сторону http://wiki.nginx.org/HttpHeadersMoreModule
Андрей, спасибо! Вопрос был решен с помощью этого модуля.
29 июня 2015 г., 15:57 пользователь Иван Мишин <simplebox66 at gmail.com>
написал:
> Дело в том, что '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 <
> alstpostbox at gmail.com> написал:
>
> Дело в том, что '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
>>>
>>
>>
>> _______________________________________________
>> 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/20150630/bbff75ec/attachment-0001.html>
Подробная информация о списке рассылки nginx-ru