502 Bad Gateway с nginx + apache + subversion + ssl (SVN COPY)

Question

У меня проблема с запуском Apache + Subversion с SSL за прокси-сервером Nginx, и я надеюсь, что кто-то может получить ответ. Я часами рыскал в гугле в поисках ответа на свою проблему и, похоже, не могу понять это. Я вижу ошибки «502 (Bad Gateway)» при попытке переместить или скопировать с использованием subversion; Тем не менее, оформление заказа и фиксация работают нормально. Вот соответствующие части (я думаю) рассматриваемых файлов конфигурации nginx и apache:

Nginx

upstream subversion_hosts {
    server 127.0.0.1:80;
}


server {
        listen       x.x.x.x:80;
        server_name  hostname;

        access_log   /srv/log/nginx/http.access_log main;
        error_log    /srv/log/nginx/http.error_log info;

        # redirect all requests to https
        rewrite ^/(.*)$ https://hostname/$1 redirect;
}

# HTTPS server
server {
        listen       x.x.x.x:443;
        server_name  hostname;

        passenger_enabled    on;
        root /path/to/rails/root;

        access_log   /srv/log/nginx/ssl.access_log main;
        error_log    /srv/log/nginx/ssl.error_log info;

        ssl                  on;
        ssl_certificate      server.crt;
        ssl_certificate_key  server.key;

        add_header Front-End-Https on;

        location /svn {
                proxy_set_header Host $host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

                set $fixed_destination $http_destination;
                if ( $http_destination ~* ^https(.*)$ )
                {
                    set $fixed_destination http$1;
                }
                proxy_set_header Destination $fixed_destination;

                proxy_pass http://subversion_hosts;
        }
}

Apache

Listen 127.0.0.1:80
<VirtualHost *:80>
        # in order to support COPY and MOVE, etc -  over https (443),
        # ServerName _must_ be the same as the nginx servername
        # http://trac.edgewall.org/wiki/TracNginxRecipe
        ServerName hostname
        UseCanonicalName on

        <Location /svn>
                DAV svn
                SVNParentPath "/srv/svn"
                Order deny,allow
                Deny from all
                Satisfy any
                # Some config omitted ...
        </Location>

        ErrorLog /var/log/apache2/subversion_error.log

        # Possible values include: debug, info, notice, warn, error, crit,
        # alert, emerg.
        LogLevel warn

        CustomLog /var/log/apache2/subversion_access.log combined
</VirtualHost>

Из того, что я мог сказать при исследовании этой проблемы, имя сервера должно совпадать как на сервере apache, так и на сервере nginx, что я и сделал. Кроме того, эта проблема, похоже, сохраняется, даже если я изменил конфигурацию на использование только http.

Answer 1

Я столкнулся с этой проблемой сегодня.

Исправлено добавление следующего в конфигурацию apache2:

RequestHeader edit Destination ^https http early

Приветствия
Игнас М

---

Источник:

• https://secure.bonkabonka.com/blog/2008/01/04/nginx_fronting_for_subversion.htm

Answer 2

Предыдущие решения у меня не работали, мне пришлось изменить конфигурацию nginx и добавить следующее в блок location перед директивой proxy_pass:

set $fixed_destination $http_destination;
if ( $http_destination ~* ^https(.*)$ ) {
    set $fixed_destination http$1;
}
proxy_set_header Destination $fixed_destination;
proxy_set_header Host $http_host;

Answer 3

Я обнаружил, что причиной моей проблемы был не прокси между nginx и apache, а проблема с самим Apache.

В первоначальном вопросе я не упомянул, что было в # Some config omitted. Этот блок содержал следующее:

AuthType Basic
AuthName "Redmine SVN Repository"
Require valid-user
PerlAccessHandler Apache::Authn::Redmine::access_handler
PerlAuthenHandler Apache::Authn::Redmine::authen_handler

Для suverversion я контролирую доступ пользователей с помощью обработчика аутентификации Redmine. После включения и выключения опций и сужения проблемы я узнал, что их модуль аутентификации не является поточно-ориентированным. Я столкнулся с ошибкой, потому что Apache использовал Worker MPM. Переход на Prefork MPM (sudo aptitude install apache2-mpm-prefork в Ubuntu) решил проблему.

Answer 4

В моем случае я использовал RouixSVN , и мне нужно было очистить аутентификацию SVN на моем компьютере и снова войти в систему, и все заработало. Надеюсь, это поможет кому-то еще.