Django 1.3 перезапись URL

В Django есть установка CommonMiddleware, которая по умолчанию добавляет косую черту к URL-адресам, которые не заканчиваются на единицу.

Например: (1) http://www.example.com/admin заменяется на (2) http://www.example.com/admin/, если он обнаружит в URLconf, что /admin/ существует.

Однако я получаю ситуацию, когда вместо (2) я получаю (3) http://www.example.com//admin/, что дает мне ошибку 404.

Это правильное поведение? Каким будет один из способов устранения ошибки 404? Большое спасибо.

Примечание. Я использую Django 1.3 + nginx + gunicorn. Я пробовал работать с Django 1.3 + nginx + apache + mod_wsgi, и я также получаю (3) (так что это не проблема веб-сервера), но я не получаю ошибку 404.

======================================================================

ОБНОВИТЬ:

Проблема в конфигурации nginx, которую я написал для перенаправления HTTP-запросов на HTTPS. Ниже приведен пример конфигурации nginx с ошибкой:

upstream django {
    server 127.0.0.1:8000;
}

server {
    listen  80; 
    server_name www.example.com;

    location / { 
        rewrite (.*) https://www.example.com/$1 permanent;
    }   
}

server {
    listen       443;
    server_name  www.example.com;

    ssl                  on;
    ssl_certificate      /home/user/certs/example.com.chained.crt;
    ssl_certificate_key  /home/user/certs/example.com.key;
    ssl_prefer_server_ciphers on;

    ssl_session_timeout  5m;

    location ~ ^/static/(.*)$ {
        alias /home/user/deploy/static/$1;
        access_log off;
        expires max;
    }

    location / {
        try_files $uri $uri/ @django_proxy;
    }

    location @django_proxy {
        proxy_pass          http://django;
        proxy_redirect      off;    
        proxy_set_header    Host                 $host;          
        proxy_set_header    X-Real-IP            $remote_addr;   
        proxy_set_header    X-Forwarded-For      $proxy_add_x_forwarded_for;
        proxy_set_header    X-Forwarded-Protocol    https;  
    }
}

Происходило следующее: CommonMiddleware перенаправляло с https://www.example.com/admin на http://www.example.com/admin/. Это снова ударило по nginx, и URL-адрес был переписан, как указано в файле конфигурации, на https://www.example.com/$1, где $1 — это «/admin/». Это означало, что конечный URL был https://www.example.com//admin/.

Чтобы исправить это, я изменил правило перезаписи на:

server {
    listen  80; 
    server_name www.example.com;

    location / { 
        rewrite /(.*) https://www.example.com/$1 permanent;
    }   
}

person quekshuy    schedule 28.06.2011    source источник


Ответы (2)


«Это правильное поведение?» Нет, это не так. За 4 года использования Djangoing я ни разу не видел такой проблемы.

Один из способов проверки того, что CommonMiddleware вызывает это, состоит в том, чтобы закомментировать его в вашем файле settings.py, перезапустить, а затем посмотреть, будет ли у вас такое же поведение. Также может быть полезно использовать автономный сервер разработки и вставлять print в интересные места, чтобы увидеть, кто его коверкает.

person Peter Rowell    schedule 28.06.2011
comment
Привет, спасибо за ответ. Я забыл упомянуть, что использую nginx в качестве обратного прокси-сервера SSL. Я запустил ванильный экземпляр Django с сервером разработки без nginx, и проблема не возникает. Глядя в него ... - person quekshuy; 29.06.2011
comment
Пожалуйста, сообщите о том, что вы найдете. Я использую nginx на нескольких сайтах, и всегда приятно знать о странностях, на которые стоит обратить внимание. - person Peter Rowell; 29.06.2011
comment
Это была моя ошибка. Спасибо за попытку указать мне в правильном направлении. Я приму ваш ответ. - person quekshuy; 29.06.2011

Проверьте свой URL. Скорее всего, вы немного неправильно определили URL. Если у тебя есть

(r'^admin', include(admin.site.urls))

вместо правильного

(r'^admin/', include(admin.site.urls)),

Вы увидите этот тип 404 с промежуточным ПО

person John    schedule 28.06.2011
comment
Привет, спасибо за ответ. Я проверил это. Это правильная версия. - person quekshuy; 29.06.2011