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

Иван Мишин simplebox66 at gmail.com
Mon Jun 29 12:57:30 UTC 2015


>
> Дело в том, что '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/20150629/5b174ebd/attachment.html>


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