Opened 18 years ago

Closed 17 years ago

#3335 closed (wontfix)

Flatpages with DEBUG=False requires 404.html

Reported by: Rob Hudson <treborhudson@…> Owned by: Adrian Holovaty
Component: Contrib apps Version: dev
Severity: Keywords:
Cc: treborhudson@… Triage Stage: Design decision needed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

While I think it is bad to not have a 404.html, I think this could be cleaner since it does work when DEBUG=False. This could lead to a broken site when it is deployed by simply changing the DEBUG setting, which I think is bad.

If flatpages and DEBUG=False and 404.html doesn't exist it throws the error:

Traceback (most recent call last):

  File "/opt/local/lib/python2.4/site-packages/django/core/servers/basehttp.py", line 272, in run
    self.result = application(self.environ, self.start_response)

  File "/opt/local/lib/python2.4/site-packages/django/core/servers/basehttp.py", line 614, in __call__
    return self.application(environ, start_response)

  File "/opt/local/lib/python2.4/site-packages/django/core/handlers/wsgi.py", line 189, in __call__
    response = self.get_response(request)

  File "/opt/local/lib/python2.4/site-packages/django/core/handlers/base.py", line 103, in get_response
    return callback(request, **param_dict)

  File "/opt/local/lib/python2.4/site-packages/django/views/defaults.py", line 78, in page_not_found
    t = loader.get_template(template_name)

  File "/opt/local/lib/python2.4/site-packages/django/template/loader.py", line 79, in get_template
    source, origin = find_template_source(template_name)

  File "/opt/local/lib/python2.4/site-packages/django/template/loader.py", line 72, in find_template_source
    raise TemplateDoesNotExist, name

TemplateDoesNotExist: 404.html

When DEBUG=False, get_response in core/handlers/base.py triggers the callback to the handler404 which is 'django.views.defaults.page_not_found' which eventually loads the template 404.html. If it doesn't exist, you get the error above.

When DEBUG=True, get_response loads the django.views.debug.technical_404_response.

I see two options for a fix (and one isn't really a "fix")...

  1. Change documentation to say that flatpages require that you have a 404.html template.
  1. Fix this so it works the same in both DEBUG states.

If #2 is the best option, this requires a design decision.

One fix could be to change get_response to know whether flatpages is enabled and switch the way it handles the call to page_not_found. But that couples the base handler to flatpages which is bad.

Another fix could be to change page_not_found to not try to load the 404.html template just yet if flatpages exists. But again, this couples flatpages to django/core when it is supposed to be a contrib app.

Not sure what the best answer is.

Change History (9)

comment:1 by Simon G. <dev@…>, 18 years ago

Triage Stage: Unreviewed → Design decision needed

I'm +1 on defaulting to a safe 404 page if nothing exists (is this also the case for 500's?)

comment:2 by Chris Beaven, 18 years ago

Regarding "safe" 404, see #760.

comment:3 by treborhudson@…, 18 years ago

I like the idea of a Django provided 404 and 500 template if one isn't provided by the user. That seems like a clean and simple solution.

comment:4 by Chris Beaven, 18 years ago

Note, however, that #666 was closed with the note that we don't want to enforce a "Django look".

Personally I'm also keen on a simple string fall back for 404 and 500 (like #760 implies)

comment:5 by Simon G. <dev@…>, 18 years ago

To avoid a "Django-look" (although the Django look is certainly nothing bad!) You could just use something similar to the standard Apache errors:

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
	<title>404 Not Found</title>
</head>
<body>
	<h1>Not Found</h1>
	
	<p>The requested URL {{ request.path|escape }} was not found on this server.</p>

	<hr>
	<address>
		<a href="http://www.djangoproject.com">Django - The Web framework for perfectionists with deadlines.</a>
	</address>
</body>
</html>

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
	<title>500 Internal Server Error</title>
</head>
<body>
	<h1>Internal Server Error</h1>
	
	<p>I'm sorry, that page is currently unavailable due to a server misconfiguration.</p>

	<p>The server administrator has been notified, and we apologise for any inconvenience.</p>

	<hr>
	<address>
		<a href="http://www.djangoproject.com">Django - The Web framework for perfectionists with deadlines.</a>
	</address>
</body>
</html>

comment:6 by Rob Hudson <treborhudson@…>, 18 years ago

Let's say we added the above 404.html and 500.html templates. Where would they go? Something like django/http/templates/?

Would these get triggered if there was a 404 (or 500) and a TemplateDoesNotExist error gets thrown?

I'd be happy to help contribute a patch if these are good ideas.

comment:7 by Jacob, 18 years ago

Resolution: → wontfix
Status: new → closed

Django's not going to ever include a default 404 or 500 template. If we do, people won't be forced to create their own, and an error will quickly reveal what software your server's running (think "Application Error (Rails)").

However, [4612] adds a comment to the line that will fail so that at least people will get a slightly better idea of where to go next.

comment:8 by Anders Hovmöller, 17 years ago

Resolution: wontfix
Status: closed → reopened

The last change of status to wont fix totally misses the point of the issue. The point is that the current code has radically different behavior in debug and release. There are two ways to fix this 1) make it display the error in debug mode or 2) make it display the flat page in non-debug mode. The comment as added by [4612] is a good thing, but clearly stops short. I got bitten by this because I turned off debug and didn't even think of checking my single flatpage. This clearly violates the principle of least surprise. If anything the behavior should be the reverse, making debug mode less lenient.

comment:9 by James Bennett, 17 years ago

Resolution: → wontfix
Status: reopened → closed

Reiterating Jacob's comment. At best, we need to make sure that the use of 404.html is documented. The rest of the behavior isn't surprising at all if you've read the flatpages docs and see how they work.

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