Inconsistent logging of 5xx and 4xx requests to django.request
The documentation for django.request
says:
Log messages related to the handling of requests. 5XX responses are raised as ERROR messages; 4XX responses are raised as WARNING messages.
The actual behaviour is not quite consistent with this:
- Only
4xx
and 500
responses are logged to django.request
- not any other responses in the 5xx
range.
500
responses are only logged if they are the result of an uncaught exception. The logging happens in django.core.handlers.base.handle_uncaught_exception
. If a view manually sets a 500
response somewhere, this isn't logged.
- The same was true of
404
responses (they were only logged if an uncaught Http404
was raised), until the change made in ticket:26504 inadvertently altered this behaviour. After that change, all 404
s are logged regardless of how they are generated.
- Other
4xx
responses meanwhile are only logged as the result of an exception (PermissionDenied
etc.), not if the status code is set manually.
400
responses are logged to django.security
but not to django.request
.
I would be happy to submit a patch that addresses this but would like some guidance on what the best solution is. My initial thoughts are:
- I think Django should log all
5xx
responses, regardless of how they were generated. This would mean refactoring the logic that does this logging.
- Either log all
4xx
responses to django.request
or change the documentation to list what specific responses are logged.
Change History
(16)
Description: |
modified (diff)
|
Triage Stage: |
Unreviewed → Accepted
|
Type: |
Uncategorized → Bug
|
Cc: |
seocam@… added
|
Owner: |
changed from nobody to Sergio Oliveira
|
Status: |
new → assigned
|
Triage Stage: |
Accepted → Ready for checkin
|
Patch needs improvement: |
set
|
Triage Stage: |
Ready for checkin → Accepted
|
Patch needs improvement: |
unset
|
Patch needs improvement: |
set
|
Patch needs improvement: |
unset
|
Triage Stage: |
Accepted → Ready for checkin
|
Resolution: |
→ fixed
|
Status: |
assigned → closed
|
The logging behavior is clearly inconsistent with the docs. The documented behavior is preferable over the current one so that's actually a bug.