#26504 closed Cleanup/optimization (fixed)
Prevent logging warnings for page "Not Found" before redirect to language-prefixed page
Reported by: | cworth-gh | Owned by: | |
---|---|---|---|
Component: | Error reporting | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Accepted | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
I've noticed that I've been getting warnings logged for things like:
Not Found: /
This results from accessing a path of "/" which is getting redirected by LocaleMiddleware to "/en/". So, in fact there is never any actual "page not found" happening here, but the code is logging based on a temporary 404 exception that the LocaleMiddleware will touch up into a redirect response.
I admit that I'm a little OCD when it comes to my log files, and I prefer them to be warning-free when nothing wrong is happening.
I've got a commit series all ready to fix this bug, which I'll try to attach to this ticket in the appropriate way, (but please let me know if I get any of the details wrong).
The pull request is here:
Change History (4)
comment:1 by , 9 years ago
Description: | modified (diff) |
---|
comment:2 by , 9 years ago
Summary: | Warnings logged for page "Not Found" before redirect to language-prefixed page → Prevent logging warnings for page "Not Found" before redirect to language-prefixed page |
---|---|
Triage Stage: | Unreviewed → Accepted |
Type: | Bug → Cleanup/optimization |
comment:3 by , 9 years ago
Owner: | set to |
---|---|
Resolution: | → fixed |
Status: | new → closed |
comment:4 by , 9 years ago
I just want to note that this change has altered the behaviour of Django's 404 logging somewhat.
Previously, Django would only log a 404 if a Http404
exception bubbled up to the core handler (and not if a view/middleware caught the exception and returned a response, regardless of whether that response was still a 404).
Now, it will log all 404 responses regardless of how they were generated. This seems better to me but there may be applications that were relying on the previous behaviour.
In 40b69607: