Why does django return 301 and 302 as server response codes after a user logs in and a flat page is displayed?

Question

I am creating a django application. Log in and display a static web page that the flatpages application manages.

Here are typical status messages from the dev server:

[15/Aug/2013 18:43:16] "GET / HTTP/1.1" 200 1263 [15/Aug/2013 18:43:23] "POST / HTTP/1.1" 302 0 [15/Aug/2013 18:43:23] "GET /home HTTP/1.1" 301 0 [15/Aug/2013 18:43:23] "GET /home/ HTTP/1.1" 200 4529 

• The first line for the login page in /. This is successfully filed, code 200.
• The second line is the input of the form. The server response code is 302, which means the page is temporarily moving.
• The third line is an attempt to get a page ('/ home') that does not exist, because the main page is served by flatpages. Server response code 301 indicates that the page has been moved permanently.
• The fourth line is the successful delivery of content ('/ home') from flatpages.

Why is the server responding with request for request 302?

What causes the third line? Why is this message sent at all? Shouldn't that be something that middleware flatpages picks up on? Does my web client send a fourth line request? How does he know that?

I think the most important question is: am I doing something wrong?

Thanks for the help!

urls.py

 urlpatterns = patterns('', url(r'^admin/', include(admin.site.urls)), url(r'^$', 'django.contrib.auth.views.login'), url(r'^logout$', 'guide.views.logout_view'), # other patterns (r'', include('django.contrib.flatpages.urls')), ) 

views.py

 def home(request): if request.user.is_authenticated() == False: return HttpResponseRedirect('/') return HttpResponseRedirect('/home/') 

Excerpt from settings.py

 MIDDLEWARE_CLASSES = ( 'django.middleware.common.CommonMiddleware', 'django.contrib.sessions.middleware.SessionMiddleware', 'django.middleware.csrf.CsrfViewMiddleware', 'django.contrib.auth.middleware.AuthenticationMiddleware', 'django.contrib.messages.middleware.MessageMiddleware', 'django.contrib.flatpages.middleware.FlatpageFallbackMiddleware', 'guide.middleware.LogActivity' ) INSTALLED_APPS = ( 'django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.sites', 'django.contrib.messages', 'django.contrib.staticfiles', 'django.contrib.flatpages', 'django.contrib.admin', 'guide', ) 

Answer 1

Based on the tip of user640916, here is how I cleared the errors.

In urls.py, I added:

 url(r'^home$', 'guide.views.home'), 

In views.py, I added:

 from django.contrib.flatpages.views import flatpage def home(request): return flatpage(request, "/home/") 

My server status messages for logging in now look like this:

 [17/Aug/2013 09:13:52] "GET / HTTP/1.1" 200 1263 [17/Aug/2013 09:14:00] "POST / HTTP/1.1" 302 0 [17/Aug/2013 09:14:00] "GET /home HTTP/1.1" 200 4529 

Not quite what I was looking for, but it works. I still have the feeling that I am not doing anything. It seems that django.contrib.auth automatically searches for the home view in the URL "/ home" without an end slash.

Answer 2

I do not see your url template for home viewing. But this is probably the missing slash that forces django to send auto-redirection:

https://docs.djangoproject.com/en/dev/ref/settings/#append-slash

Does my web client send a fourth line request? How does this know about this?

Yes, the status code 301 on line 3 tells the browser that the page you requested has moved to another URL x. And browsers usually always automatically send a new request to this new url x, which is line 4.

Answer 3

I can not comment or double-check, but I wanted to add for others that beluga.me in fooobar.com/questions/1497352 / ... was in place, and after my success_url I lacked the trait.

It:

 success_url = 'step-two' 

changed to:

 success_url = 'step-two/' 

fixed it.