Well my last reply was preemptery.
A minimal working example can be produced via the following commands. First
navigate to a suitable directory then,
# virtualenv venv --no-site-packages
# source venv/bin/activate
# pip install django
# django-admin startproject mwe
# vim mwe/mwe/settings.y
and then entering the following at the end of the settings.py file:
LOGGING = {
'version': 1,
'disable_existing_loggers': False,
'formatters': {
'django.server': {
'()': 'django.utils.log.ServerFormatter',
'format': '[%(server_time)s] %(message)s %(request)r',
}
},
'handlers': {
'django.server': {
'level': 'INFO',
'class': 'logging.StreamHandler',
'formatter': 'django.server',
},
},
'loggers': {
'django.server': {
'handlers': ['django.server'],
'level': 'INFO',
'propagate': False,
},
}
}
Then :wq
# cd mwe
# python manage.py runserver
Navigate to http://127.0.0.1:8000/blargh
The normal error message about routing will show. Switch back to the
console and you'll see:
# python manage.py runserver
Performing system checks...
System check identified no issues (0 silenced).
September 15, 2016 - 23:12:05
Django version 1.10.1, using settings 'mwe.settings'
Starting development server at http://127.0.0.1:8000/
Quit the server with CONTROL-C.
Not Found: /blargh
[15/Sep/2016 23:12:09] "GET /blargh HTTP/1.1" 404 1918
<socket._socketobject object at 0x7fa14d58da60>
That representation of the socket object is being produced by the
"%(request)r" in the formatter.
Chasing this back through the call stack the request object is set
in /usr/lib/python2.7/SocketServer.py(652)__init__() as the socket. This is
seems reasonable to me, so I guess some kind of processing of the request
isn't being performed somewhere.
On Friday, 16 September 2016 08:16:09 UTC+10, Ben Whale wrote:
>
> Thanks for the reply Tim
>
> Some testing seems to indicate that it is an issue with
> django-rest-framework. When I contact the web server using urls managed by
> django rest the issues occurs, when I do the same via url managed by
> vanilla django the request variable in the context object is an instance of
> WSGIRequest, which is far more sensible.
>
> I'm doing to do some more digging today to prove this and, assuming I'm
> right, will pass the bug onto the django rest guys.
>
> Any hints on debugging this? I haven't entered the django code base much
> before.
>
> On Thursday, 15 September 2016 23:21:59 UTC+10, Tim Graham wrote:
>>
>> If true, it does seem like a bug. Could you provide a test for Django's
>> test suite or a sample project to reproduce it?
>>
>> On Thursday, September 15, 2016 at 6:53:55 AM UTC-4, Ben Whale wrote:
>>>
>>> Hi
>>>
>>> What I'd like to do is log the request body whenever the django.request
>>> logger logs something. I had assumed that the extra context referred to as
>>> request in
>>> https://docs.djangoproject.com/en/1.10/topics/logging/#django-request
>>> was something like an HTTPRequest object. It is, however, an instance
>>> of socket._socketobject.
>>>
>>> Is it possible to get data for logging using the socket? For example the
>>> get parameters, the post data, any information associated to a file that
>>> was sent like what every has been read out of the socket? What about the
>>> request headers?
>>>
>>> Why is a socket passed to the logger? I must admit that I assume this to
>>> be a bug. The user has a very limited way of interacting with the socket
>>> via the string formatting syntax and the methods of the socket (as
>>> introspected via dir) don't lend them selves to this form of access.
>>>
>>> I'm currently using django 1.10 if that helps.
>>>
>>> Thanks for any help.
>>>
>>>
>>>
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/e7178731-aa2c-4f93-ac33-d8a795a33954%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
