Назад | Перейти на главную страницу

Сбой переименования WebDav при установке Apache mod_dav за NginX

Пытаюсь решить проблему с переименованием файлов через WebDav. Наш стек состоит из одной машины, обслуживающей контент через Nginx, Varnish и Apache. Когда вы пытаетесь переименовать файл, операция не выполняется со стеком, который мы сейчас используем.

Для подключения к WebDav клиентская программа должна:

Подключиться через https: // хост: 443 в NginX
NginX разворачивает и перенаправляет запрос на сервер Varnish на http: // локальный: 81
Varnish пересылает запрос в Apache на http: // локальный: 82, который предлагает сеанс через mod_dav

Вот пример неудачного переименования:

$ cadaver https://webdav.domain/
Authentication required for Webdav on server `webdav.domain':
Username: user
Password:

dav:/> cd sandbox
dav:/sandbox/> mkdir test
Creating `test': succeeded.

dav:/sandbox/> ls
Listing collection `/sandbox/': succeeded.
Coll:   test                                   0  Mar 12 16:00

dav:/sandbox/> move test newtest
Moving `/sandbox/test' to `/sandbox/newtest':  redirect to http://webdav.domain/sandbox/test/

dav:/sandbox/> ls
Listing collection `/sandbox/': succeeded.
Coll:   test                                   0  Mar 12 16:00

Для получения дополнительной информации клиент Windows WebDrive зарегистрировал ошибку 502 (Плохой шлюз) и 303 (?) При операции переименования. В расширенных журналах содержится следующая информация:

URI назначения относится к другой схеме или порту (https: // имя хоста: 443) (хотеть: http: // имя хоста: 82).

Некоторые другие ограничения: исследования модулей NginX Webdav показывают, что он действительно не соответствует нашим потребностям, и пересылка трафика webdav на Apache не является вариантом, потому что мы не хотим включать Apache SSL.

Есть ли способы обмануть mod_dav для пересылки на другой хост? Я открыт для идей :).

(Вернувшись к тем временам, когда я использовал Subversion) У меня была аналогичная проблема с проксированием на Apache SVN из внешнего интерфейса Nginx SSL. Предположим, что веб-интерфейс Nginx SSL является хостом https: //, и мы хотим прокси-соединения с внутренним сервером Apache SVN http: // svn.

Проблема возникает при попытке скопировать ресурс с Destination заголовок:

COPY /path HTTP/1.1
Host: host
Destination: https://host/another_path

Как вы видете Destination заголовок все еще содержит https схема. Исправление довольно очевидно -

location / {
    # to avoid 502 Bad Gateway:
    # http://vanderwijk.info/Members/ivo/articles/ComplexSVNSetupFix
    set $destination $http_destination;

    if ($destination ~* ^https(.+)$) {
         set $destination http$1;
    }

    proxy_set_header Destination $destination;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $remote_addr;

    proxy_pass http://svn;
}

Как сказал @Cnly, используя set директива не будет работать, если в исходном Destination заголовок и URL. (Я не имею понятия почему)

Я использовал директиву map для решения проблемы.

http {
    map $http_destination $http_destination_webdav {
        ~*https://(.+) http://$1;
        default $http_destination;
    }

    server {
        # ...server settings...

        location / {
            proxy_set_header Host $host;
            proxy_set_header X-Forwarded-For $remote_addr;
            proxy_set_header Destination $http_destination_webdav;

            proxy_pass http://svn;
        }
    }
}