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 404s 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.