Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#30475 closed Bug (invalid)

Use of i18n_patterns and a buggy 404 template trigger internal server error without a backtrace.

Reported by: Erik Stein Owned by: nobody
Component: Core (URLs) Version: dev
Severity: Normal Keywords:
Cc: Erik Stein Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description (last modified by Erik Stein)

– Using i18n_patterns with prefix_default_language=True,
– trying to get the frontpage URL without a language given in the URL

works in debug mode, but gives an internal server error without any backtrace in production mode.

This was caused by a buggy 404.html template, but probably buggy 404 templates should give a backtrace, too, and i18n_patterns shouldn't be concerned by this anyway.

Sample project: https://github.com/sha-red/bugs-django-30475

Change History (6)

comment:1 by Claude Paroz, 5 years ago

Probably setting up a minimal project to reproduce the issue would be great.

in reply to:  description comment:2 by Carlton Gibson, 5 years ago

Resolution: needsinfo
Status: newclosed

Replying to Erik Stein:

[draft bug report, I'll try to provide more details later or on request]

Hi Erik.

Happy to look at this but, as Claude says, could you provide a sample project the reproduces the issue?

What exactly is the issue? An error in the 404 template? That i18n patterns swallows that? (Is it in fact dependent on i18n patterns?) And so on.

Thanks.

comment:3 by Erik Stein, 5 years ago

Cc: Erik Stein added
Description: modified (diff)
Resolution: needsinfo
Status: closednew

I asked about adding a ticket for later reference before posting the issue and I would consider closing it after two days a bit unfortunate, but I don't really know your triaging policy, so please forgive me :-).

Today I've added a simple sample project. In a first check it seems that the Django test client actually deals correctly with the buggy 404 template (delivering a backtrace) making it somehow unuseful in testing the issue. I added some notes in the README instead.

comment:4 by Mariusz Felisiak, 5 years ago

Resolution: invalid
Status: newclosed
Summary: Use of i18n_patterns and a buggy 404 template trigger internal server error without a backtraceUse of i18n_patterns and a buggy 404 template trigger internal server error without a backtrace.
Version: 2.2master

Thanks for the sample project. IMO everything works properly. In DEBUG mode Django doesn't use your custom 404.html page that's why it also doesn't propagate any errors in this page (you've already described this as a correct behavior). When DEBUG=False Django handles exception by handler500 view and logges them in django.request logger. If you want to skip this and propagate exceptions upwards when DEBUG=False you can use DEBUG_PROPAGATE_EXCEPTIONS setting.

comment:5 by Erik Stein, 5 years ago

Resolution: invalid
Status: closednew

Please forgive me for reopening the ticket again!

I guess my original question and reason to open a ticket was that I'm irritated that i18n_patterns will break in production mode if you have a buggy 404 template, instead of just redirecting to the correct URL. This doesn't seem to be correct behaviour in my eyes.

comment:6 by Carlton Gibson, 5 years ago

Resolution: invalid
Status: newclosed

Hi Erik.

Sorry for your irritation. I understand these things can be frustrating.

I don't really know your triaging policy, so please forgive me :-).

See TicketClosingReasons/DontReopenTickets and The Triage Workflow docs.

Ultimately here I think it's up to the user to ensure their 404 template loads correctly. That's straight-forward to test. If they do introduce an error, yes we drop right through to the very bottom handle_uncaught_exception() but we know something bad has happened in that case. As Mariusz points you to, DEBUG_PROPAGATE_EXCEPTIONS reveals the issue immediately.

A custom 404 handler adding logging and/or exception handling around the get_template() call would be possible. But it's unnecessary overhead: a simple test that the 404.html template does in fact load makes this redundant.

Sorry if that's not what you want to hear.

Last edited 5 years ago by Carlton Gibson (previous) (diff)
Note: See TracTickets for help on using tickets.
Back to Top