Попробуйте в @delete_handler в rewrite добавить 'break'. Так как в
access_логе фигурирует 598, то похоже на то, что @delete_handler
отрабатывает, отрабатывает rewrite, после чего запрос уходит снова в
'location ^~ /Family', опять отрабатывает 'return 598', но так как
recursive_error_pages по-умолчанию выключена, error_page на этот раз не
срабатывает, и клиент получает 598.

25 июня 2015 г., 9:28 пользователь Иван Мишин <simplebox66@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@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