#27234: django.request receives a socket object rather than a request object in
logging
-------------------------+-------------------------------------------------
Reporter: ben- | Owner: nobody
whale |
Type: Bug | Status: new
Component: | Version: 1.10
Uncategorized | Keywords: django.request runserver
Severity: Normal | WSGIRequest socket
Triage Stage: | Has patch: 0
Unreviewed |
Easy pickings: 0 | UI/UX: 0
-------------------------+-------------------------------------------------
This bug (if indeed it is a bug) is probably related to: #27233
(https://code.djangoproject.com/ticket/27233).
The documentation for the django.request logger
(https://docs.djangoproject.com/en/1.10/topics/logging/#django-request)
implies that the request variable (passed in as extra context) is a
request (or something request like). Instead, it can be either an
instance of WSGIRequest or socket.
I expected it to be something request like so that it would be possible to
log the GET parameters or the POST data. I'm pretty sure that the socket
the webserver listens to shouldn't be passed to a logging object that a
user could then interact with.
How to replicate:
I'm going to give to examples, the first will show that the request
variable is a socket, the second will show that it is sometimes a
WSGIRequest and sometimes a socket.
First example:
1) install vanilla django and set up a project.
2) Put the following into the settings.py file:
{{{
LOGGING = {
'version': 1,
'disable_existing_loggers': False,
'formatters': {
'custom': {
'()': 'django.utils.log.ServerFormatter',
'format': '[%(server_time)s] %(message)s %(request)r',
}
},
'handlers': {
'custom': {
'level': 'INFO',
'class': 'logging.StreamHandler',
'formatter': 'custom',
},
},
'loggers': {
'django.request': {
'handlers': ['custom'],
'level': 'DEBUG',
'propagate': False,
},
}
}
}}}
3) Edit the file <path_to_django_install>/django/utils/log.py and put the
following {{{print repr(record.request)}}} into the format method of the
ServerFormatter object
4) use {{{python manage.py runserver}}} to launch the server
5) navigate to a valid page, e.g. 127.0.0.1:8000 (I use port 8001 because
reasons)
You should see something like
{{{
# python manage.py runserver 8001
System check identified no issues (0 silenced).
September 16, 2016 - 06:01:12
Django version 1.10.1, using settings 'mwe.settings'
Starting development server at http://127.0.0.1:8001/
Quit the server with CONTROL-C.
<socket._socketobject object at 0x7fc4fccc4c90>
[16/Sep/2016 06:01:14] "GET / HTTP/1.1" 200 1767
}}}
The line {{{<socket._socketobject object at 0x7fc4fccc4c90>}}} is the
string representation of the request.
Second example:
Using the same set up as for the first example navigate to an invalid
page, e.g. {{{127.0.0.1:8001/foo}}}
You should see something like
{{{
System check identified no issues (0 silenced).
September 16, 2016 - 06:06:15
Django version 1.10.1, using settings 'mwe.settings'
Starting development server at http://127.0.0.1:8001/
Quit the server with CONTROL-C.
<WSGIRequest: GET '/foo'>
Traceback (most recent call last):
File "/usr/lib/python2.7/logging/__init__.py", line 861, in emit
msg = self.format(record)
File "/usr/lib/python2.7/logging/__init__.py", line 734, in format
return fmt.format(record)
File "/home/benwhale/Documents/Projects/mwe/venv/local/lib/python2.7
/site-packages/django/utils/log.py", line 174, in format
if args[1][0] == '2':
IndexError: tuple index out of range
Logged from file base.py, line 152
<socket._socketobject object at 0x7f4997751a60>
[16/Sep/2016 06:06:18] "GET /foo HTTP/1.1" 404 1909
}}}
on the command line. Please ignore the IndexError for the purposes of this
bug see https://code.djangoproject.com/ticket/27233. Observe the two lines
{{{<WSGIRequest: GET '/foo'>}}} and {{{<socket._socketobject object at
0x7f4997751a60>}}} these indicate that the request object can be either a
WSGIRequest or a socket object.
Placing a break point in the format method is not sufficient to see both
calls with WSGIRequest and socket objects as, at least for me, the break
point would only trigger once.
The code paths that result in both calls are slightly different and result
from a difference in the handlers array in the Logger object. This
difference in code path also responsible for the IndexError and so fixing
this ticket is likely to be related to fixing ticket #27233.
--
Ticket URL: <https://code.djangoproject.com/ticket/27234>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/052.73fac9d9c65589e81f4400c4fff57b33%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
