Opened 7 years ago

Closed 6 years ago

#9678 closed (invalid)

Flatpage with URL of "/" ends up in a redirect loop.

Reported by: watusee Owned by: nobody
Component: Uncategorized Version: 1.1-beta
Severity: Keywords: flatpage
Cc: chris@… Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

Picture a site with a flatpage at the root. This root flatpage in the
admin tool has a "/" for the URL. The root flatpage gets into a
redirect loop. All other flatpages except the root flatpage work fine.
If Append_Slash is set to false, this perplexing behavior no longer
occurs and the root flatpage works just fine.

Attachments (2)

settings.py (3.1 KB) - added by watusee 7 years ago.
Settings.py
urls.py (868 bytes) - added by watusee 7 years ago.
urls.py

Download all attachments as: .zip

Change History (15)

comment:1 follow-up: Changed 7 years ago by dih0658

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to worksforme
  • Status changed from new to closed

I've been using a site with a flatpage as it's root for quite some time. I went back to double check that I wasn't losing my mind and tried both APPEND_SLASH options. All works just fine for me.

Changed 7 years ago by watusee

Settings.py

Changed 7 years ago by watusee

urls.py

comment:2 in reply to: ↑ 1 Changed 7 years ago by watusee

  • Resolution worksforme deleted
  • Status changed from closed to reopened

Should have mentioned earlier using Python 2.5 with Django 1.02. It happens with both the built-in server and on Web Faction using mod_python. I've attached the setting.py and urls.py to see if I'm doing something unusual or wrong.

Replying to dih0658:

I've been using a site with a flatpage as it's root for quite some time. I went back to double check that I wasn't losing my mind and tried both APPEND_SLASH options. All works just fine for me.

comment:3 follow-up: Changed 7 years ago by dc

The problem is in django.contrib.flatpages.url in line:

(r'^(?P<url>.*)$', 'flatpage'),

It makes

if not url.endswith('/') and settings.APPEND_SLASH:
    return HttpResponseRedirect("%s/" % request.path)

in flatpage view return redirect 302.

According to Porting Guide URLconf must be changed to

(r'^(?P<url>.*/)$', 'flatpage'),

This change fixes the problem.

comment:4 in reply to: ↑ 3 Changed 7 years ago by dc

Another way is to remove

(r'', include('django.contrib.flatpages.urls'))

from your URLconf and keep only FlatpageFallbackMiddleware. This also fixes the problem.

comment:5 follow-up: Changed 7 years ago by mtredinnick

Comment 3 is not correct. Flatpage URLs are not required to end in trailing slashes, so the proposed change there would break those URLs (the ones without a trailing slash).

The real problem is that identified in comment 4. There is no reason to include the flatpage URLs in urls.py. That isn't what the documentation says to do. Since flatpages operate by catching URLs that do not otherwise resolve, they aren't necessarily going to work if you include them explicitly.

If the original poster can confirm that removing that line from urls.py makes the problem go away, we can close this as not being a bug in Django (i.e. invalid). It's just a configuration error.

Nice debugging, dc. :-)

comment:6 in reply to: ↑ 5 Changed 7 years ago by dc

Flatpage URLs are not required to end in trailing slashes

Yes, but because of

if not url.endswith('/') and settings.APPEND_SLASH:
    return HttpResponseRedirect("%s/" % request.path)

there is always /page -> /page/ redirect.

This lines were introduced in [8218] as a fix for #6213 and bug seems still there. So this ticket looks like some kind of #6213 duplicate.

comment:7 Changed 6 years ago by anonymous

  • milestone post-1.0 deleted

Milestone post-1.0 deleted

comment:8 Changed 6 years ago by jacob

  • Resolution set to wontfix
  • Status changed from reopened to closed

I agree with Malcolm; this is a configuration error.

comment:9 follow-up: Changed 6 years ago by flaccid

  • Cc chris@… added
  • Needs documentation set
  • Needs tests set
  • Resolution wontfix deleted
  • Status changed from closed to reopened
  • Version changed from 1.0 to 1.1-beta-1

I am using (1, 1, 0, 'beta', 1) and this problem still occurs.
There is no justification above why this is a configuration problem. I have attempted to use all the before-mentioned url patterns, APPEND_SLASH on or off, as well as falling back to middleware. There is still, always a redirect loop in my version.
People have reported that it 'works for me' using flat pages and the URL pattern (r, include('django.contrib.flatpages.urls')),
That is good for them, but i am doing the same thing, no extra configuration, tested with a fresh project, implementing the exact same examples from the docs and 'Practical Django Projects' and there is always a redirect loop.
jacob - what is this configuration error you speak of and please detail the correct configuration?

I include 'django.contrib.flatpages' in INSTALLED_APPS and apply (r, include('django.contrib.flatpages.urls')), in urls.py (or any of the alternate url patterns mentioned above) with a page added via admin under URL '/' and I will always get a redirect loop.

Please do not close this ticket again blindly.

comment:10 in reply to: ↑ 9 ; follow-up: Changed 6 years ago by flaccid

Replying to flaccid:
apologies forgot to escape the code, of course that reads

(r'', include('django.contrib.flatpages.urls')),

comment:11 in reply to: ↑ 10 Changed 6 years ago by Daniel Harris

Replying to flaccid:

Replying to flaccid:
apologies forgot to escape the code, of course that reads

(r'', include('django.contrib.flatpages.urls')),

I believe Malcom's comments above explain (and fix) the problem. For flatpages you shouldn't be including anything in your urls.py. The flatpages app catches exceptions for pages that do not exist and then look them up in the DB before actually throwing a page not found.

comment:12 Changed 6 years ago by flaccid

Replying to Daniel Harris:

Replying to flaccid:

Replying to flaccid:
apologies forgot to escape the code, of course that reads

(r'', include('django.contrib.flatpages.urls')),

I believe Malcom's comments above explain (and fix) the problem. For flatpages you shouldn't be including anything in your urls.py. The flatpages app catches exceptions for pages that do not exist and then look them up in the DB before actually throwing a page not found.

Unfortunately not. I have also tested that on many projects. It throws a HTTP 500 for me with the following traceback example:

[Mon Jul 06 22:35:16 2009] [error] [client 192.168.0.102] mod_wsgi (pid=34592): Exception occurred processing WSGI script '/www/django-projects/foo/apache/foo.wsgi'., referer: http://foo.bar/
[Mon Jul 06 22:35:16 2009] [error] [client 192.168.0.102] Traceback (most recent call last):, referer: http://foo.bar/
[Mon Jul 06 22:35:16 2009] [error] [client 192.168.0.102]   File "/usr/local/lib/python2.6/site-packages/django/core/handlers/wsgi.py", line 241, in __call__, referer: http://foo.bar/
[Mon Jul 06 22:35:16 2009] [error] [client 192.168.0.102]     response = self.get_response(request), referer: http://foo.bar/
[Mon Jul 06 22:35:16 2009] [error] [client 192.168.0.102]   File "/usr/local/lib/python2.6/site-packages/django/core/handlers/base.py", line 122, in get_response, referer: http://foo.bar/
[Mon Jul 06 22:35:16 2009] [error] [client 192.168.0.102]     return self.handle_uncaught_exception(request, resolver, sys.exc_info()), referer: http://foo.bar/
[Mon Jul 06 22:35:16 2009] [error] [client 192.168.0.102]   File "/usr/local/lib/python2.6/site-packages/django/core/handlers/base.py", line 166, in handle_uncaught_exception, referer: http://foo.bar/
[Mon Jul 06 22:35:16 2009] [error] [client 192.168.0.102]     return callback(request, **param_dict), referer: http://foo.bar/
[Mon Jul 06 22:35:16 2009] [error] [client 192.168.0.102]   File "/usr/local/lib/python2.6/site-packages/django/views/defaults.py", line 23, in server_error, referer: http://foo.bar/
[Mon Jul 06 22:35:16 2009] [error] [client 192.168.0.102]     t = loader.get_template(template_name) # You need to create a 500.html template., referer: http://foo.bar/
[Mon Jul 06 22:35:16 2009] [error] [client 192.168.0.102]   File "/usr/local/lib/python2.6/site-packages/django/template/loader.py", line 81, in get_template, referer: http://foo.bar/
[Mon Jul 06 22:35:16 2009] [error] [client 192.168.0.102]     source, origin = find_template_source(template_name), referer: http://foo.bar/
[Mon Jul 06 22:35:16 2009] [error] [client 192.168.0.102]   File "/usr/local/lib/python2.6/site-packages/django/template/loader.py", line 74, in find_template_source, referer: http://foo.bar/
[Mon Jul 06 22:35:16 2009] [error] [client 192.168.0.102]     raise TemplateDoesNotExist, name, referer: http://foo.bar/
[Mon Jul 06 22:35:16 2009] [error] [client 192.168.0.102] TemplateDoesNotExist: 500.html, referer: http://foo.bar/

comment:13 Changed 6 years ago by flaccid

  • Needs documentation unset
  • Needs tests unset
  • Resolution set to invalid
  • Status changed from reopened to closed

Works with or without the error templates although the docs do say they are required (which doesn't make logical sense to me since they won't be rendered if there is a flatpage available).

After a restart in this instance of the django web server, it is working without 500 and 404 error page templates. If anyone else gets in this situation, I suggest (thanks to the assistance of Danial Harris also) to stop your django web server, syncdb and start it again. I originally did syncdb when I originally implemented flatpages and FlatpageFallbackMiddleware however for some reason this was not suffice. I assume restarting the server was for some reason required - perhaps caching issue with the pyc files.. not sure.

Note: See TracTickets for help on using tickets.
Back to Top