2009-10-20 4 views
57

Mam dwie aplikacje znajdujące się na dwóch oddzielnych komputerach. Na komputerze w pliku urls.py mam linię tak:Adresy URL django bez ukośnego ukośnika nie przekierowują

(r'^cast/$', 'mySite.simulate.views.cast') 

a ten adres będzie działać zarówno mySite.com/cast/ i mySite.com/cast. Ale na komputerze BI mają podobną url pisemnego się następująco:

(r'^login/$', 'mySite.myUser.views.login') 

Z jakiegoś powodu na komputerze B url mySite.com/login/zadziała ale mySite.com/login zawiśnie i nie skieruje z powrotem do mySite.com/login/ jak to będzie na komputerze A. Czy coś tam przeoczyłem? Oba pliki url.py wyglądają identycznie jak ja.

Odpowiedz

73

sprawdzić ustawienie APPEND_SLASH w pliku settings.py

more info in the django docs

+2

„Gdy ustawiona na True, jeżeli żądanie URL nie pasuje do żadnej z tych wzorów w URLconf i to nie kończy się ukośnikiem, przekierowanie HTTP jest wysyłane do tego samego adresu URL z dołączonym ukośnikiem Zwróć uwagę, że przekierowanie może spowodować utratę wszystkich danych przesłanych w żądaniu POST. ". "Ustawienie APPEND_SLASH jest używane tylko wtedy, gdy zainstalowano CommonMiddleware ...". Wolę odpowiedź od Michaela Gendina, by uzyskać czystsze rozwiązanie. – Wtower

+0

To nie działa, jeśli korzystasz z dodatkowego adresu URL "catch all" przy ostatnim wpisie swoich znaków url. Odpowiedź @ speedplane będzie działać nawet w tych sytuacjach. Ale oczywiście jest to prostsze i powinno być używane, jeśli nie ma wpisów "catch all" urlpattern. – np8

139

Albo można napisać swoje adresy URL tak:

(r'^login/?$', 'mySite.myUser.views.login') 

Znak zapytania po ukośnika sprawia, że ​​opcja w regexp. Użyj go, jeśli z pewnych przyczyn nie chcesz używać ustawienia APPEND_SLASH.

+6

Zadzwoń do mnie naiwnie - ale dlaczego ta odpowiedź nie dostała miliona awansów i wpisu w django faq? –

+35

Na pewno nie chcesz tego robić ze względu na SEO - lepiej przekierować do kanonicznego adresu URL niż dwa prawidłowe adresy URL. –

+35

Jeśli tworzysz RESTful API przy użyciu Django, może to być dobre rozwiązanie, gdy programiści POST bezpośrednio pod adresem URL punktu końcowego. Gdy używasz 'APPEND_SLASH', jeśli przypadkowo wysłał go bez ukośnego ukośnika, a twój URL ma Z końcowym ukośnikiem, otrzymają wyjątek dotyczący utraty danych podczas przekierowywania żądań POST. – OrPo

0

Miałem ten sam problem. W moim przypadku to było nieświeże resztki z jakiejś starej wersji w urls.py, sprzed staticfiles:

url(r'^%s(?P<path>.*)$' % settings.MEDIA_URL.lstrip('/'), 
    'django.views.static.serve', 
    kwargs={'document_root': settings.MEDIA_ROOT}), 

MEDIA_URL był pusty, więc ten wzór pasuje wszystko.

2

Miałem ten sam problem. Moje rozwiązanie zostało umieszczone (| /) przed końcową linią mojego regularnego wyrażenia.

url(r'^artists/(?P[\d]+)(|/)$', ArtistDetailView.as_view()),

9

Poprawia to na odpowiedź @Michael Gendin użytkownika. Jego odpowiedź służy identycznej stronie z dwoma osobnymi adresami URL. Byłoby lepiej mieć login automatycznie przekierowywać do login/, a następnie służyć ten ostatni jako stronę główną:

from django.conf.urls import patterns 
from django.views.generic import RedirectView 

urlpatterns = patterns('', 
    # Redirect login to login/ 
    (r'^login$', RedirectView.as_view(url = '/login/')), 
    # Handle the page with the slash. 
    (r'^login/', "views.my_handler"), 
) 
+2

To bardzo ładny i oczywisty sposób! – Nevertheless