Django: Ticket Queryhttps://code.djangoproject.com/query?status=!closed&keywords=~wsgi&order=owner
The Web framework for perfectionists with deadlines.en-USDjangohttps://www.djangoproject.com/s/img/site/hdr_logo.gifhttps://code.djangoproject.com/query?status=!closed&keywords=~wsgi&order=owner
Trac 1.2https://code.djangoproject.com/ticket/12075
https://code.djangoproject.com/ticket/12075#12075: Add wsgiorg.routing args supportThu, 22 Oct 2009 16:06:12 GMTGustavo Narea<p>
The <a class="ext-link" href="http://wsgi.readthedocs.org/en/latest/specifications/routing_args.html"><span class="icon">​</span>wsgiorg.routing_args</a> standard may be really useful if you want to use WSGI middleware or applications inside Django because some of them take advantage of that to do nice/useful things.
</p>
<p>
It's currently not supported in Django - But it will with the attached patch.
</p>
<p>
<em>[edit] fixed broken link.</em>
</p>
Resultshttps://code.djangoproject.com/ticket/12075#changeloghttps://code.djangoproject.com/ticket/12091
https://code.djangoproject.com/ticket/12091#12091: Support for WSGI applications within DjangoMon, 26 Oct 2009 17:42:30 GMTGustavo Narea<p>
With the attached patch, it will be possible to run WSGI applications from Django and even use such applications as Django views.
</p>
<p>
It depends on the patch I supplied in <a class="closed ticket" href="https://code.djangoproject.com/ticket/8927" title="#8927: New feature: Make Request proxy the WSGI environ (closed: wontfix)">#8927</a>.
</p>
<p>
Please let me know what you think about it.
</p>
Resultshttps://code.djangoproject.com/ticket/12091#changeloghttps://code.djangoproject.com/ticket/20589
https://code.djangoproject.com/ticket/20589#20589: contrib.auth.handlers.modwsgi fails for some backendsTue, 11 Jun 2013 20:44:18 GMTAndre Bell<p>
In contrib.auth.handlers.modwsgi authentication is implemented with a check_password function, which in turn is based on "user.check_password". However, this forces a check of the given password against the password stored in the database.
</p>
<p>
For some backends like, e.g. django_auth_ldap, no usable password is stored in the database. Thus, this check will fail.
</p>
<p>
Therefore the function should be implemented using a call to "authenticate", which will correctly verify the given password against the different authentication backends.
</p>
Resultshttps://code.djangoproject.com/ticket/20589#changeloghttps://code.djangoproject.com/ticket/25203
https://code.djangoproject.com/ticket/25203#25203: Document changes to WSGI application loading sequence in 1.7Fri, 31 Jul 2015 16:07:17 GMTyscumc<p>
After upgrading Django from 1.6 to 1.7, I found that there were some undocumented differences in how the wsgi loading is handled.
</p>
<p>
I had the following in Django 1.6 in my wsgi.py:
</p>
<pre class="wiki">from django.core.wsgi import get_wsgi_application
_application = get_wsgi_application()
# Update DJANGO_SETTINGS_MODULE os env variable from internal Apache env variable, set by "SetEnv" in httpd.conf
def application(environ, start_response):
if 'DJANGO_SETTINGS_MODULE' in environ:
os.environ['DJANGO_SETTINGS_MODULE'] = environ['DJANGO_SETTINGS_MODULE']
return _application(environ, start_response)
</pre><p>
This will get the env from the Apache conf and set it before a request to make sure that the proper settings file is loaded.
</p>
<p>
However, in Django 1.7, this broke because <code>django.setup()</code> is now run as part of <code>django.core.wsgi.get_wsgi_application()</code> and this causes the settings file to be loaded before the first <code>application()</code> call (first request).
</p>
<p>
Previously, the loading of the settings file seems to happen with the first <code>application()</code> call, <code>django.core.wsgi.get_wsgi_application()()</code>.
</p>
<p>
Debugging this was actually more difficult than it seems. I initially just got a 400 BAD REQUEST error after upgrading, with no errors in the logs. It took a long time to realize my my custom settings file wasn't being loaded and so <code>ALLOWED_HOSTS</code> weren't being loaded either.
</p>
<p>
After finding out it was a changed behavior in wsgi loading that was causing the problem, fixing the problem was straightforward, but I recommend updating the documentation with this change in Django 1.7 so that others wouldn't run into this issue.
</p>
<p>
Here's the fixed version that also works with 1.7 (and earlier) if someone is interested:
</p>
<pre class="wiki"># Update DJANGO_SETTINGS_MODULE os env variable from internal Apache env variable, set by "SetEnv" in httpd.conf
def application(environ, start_response):
if 'DJANGO_SETTINGS_MODULE' in environ:
os.environ['DJANGO_SETTINGS_MODULE'] = environ['DJANGO_SETTINGS_MODULE']
# Only attempt to execute get_wsgi_application() once
if not application._app:
application._app = get_wsgi_application()
return application._app(environ, start_response)
application._app = None
</pre>Resultshttps://code.djangoproject.com/ticket/25203#changeloghttps://code.djangoproject.com/ticket/27234
https://code.djangoproject.com/ticket/27234#27234: Clarify the type of the django.server logger's 'request' extra contextFri, 16 Sep 2016 06:12:55 GMTBen Whale<p>
This bug (if indeed it is a bug) is probably related to: <a class="closed ticket" href="https://code.djangoproject.com/ticket/27233" title="#27233: Bug: IndexError when using django.request (closed: invalid)">#27233</a> (<a href="https://code.djangoproject.com/ticket/27233">https://code.djangoproject.com/ticket/27233</a>).
</p>
<p>
The documentation for the django.request logger (<a class="ext-link" href="https://docs.djangoproject.com/en/1.10/topics/logging/#django-request"><span class="icon">​</span>https://docs.djangoproject.com/en/1.10/topics/logging/#django-request</a>) 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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
First example:
1) install vanilla django and set up a project.
2) Put the following into the settings.py file:
</p>
<pre class="wiki">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,
},
}
}
</pre><p>
3) Edit the file &lt;path_to_django_install&gt;/django/utils/log.py and put the following <code>print repr(record.request)</code> into the format method of the ServerFormatter object
4) use <code>python manage.py runserver</code> to launch the server
5) navigate to a valid page, e.g. 127.0.0.1:8000 (I use port 8001 because reasons)
</p>
<p>
You should see something like
</p>
<pre class="wiki"># 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.
&lt;socket._socketobject object at 0x7fc4fccc4c90&gt;
[16/Sep/2016 06:01:14] "GET / HTTP/1.1" 200 1767
</pre><p>
The line <code>&lt;socket._socketobject object at 0x7fc4fccc4c90&gt;</code> is the string representation of the request.
</p>
<p>
Second example:
Using the same set up as for the first example navigate to an invalid page, e.g. <code>127.0.0.1:8001/foo</code>
</p>
<p>
You should see something like
</p>
<pre class="wiki">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.
&lt;WSGIRequest: GET '/foo'&gt;
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
&lt;socket._socketobject object at 0x7f4997751a60&gt;
[16/Sep/2016 06:06:18] "GET /foo HTTP/1.1" 404 1909
</pre><p>
on the command line. Please ignore the IndexError for the purposes of this bug see <a href="https://code.djangoproject.com/ticket/27233">https://code.djangoproject.com/ticket/27233</a>. Observe the two lines <code>&lt;WSGIRequest: GET '/foo'&gt;</code> and <code>&lt;socket._socketobject object at 0x7f4997751a60&gt;</code> these indicate that the request object can be either a WSGIRequest or a socket object.
</p>
<p>
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.
</p>
<p>
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 <a class="closed ticket" href="https://code.djangoproject.com/ticket/27233" title="#27233: Bug: IndexError when using django.request (closed: invalid)">#27233</a>.
</p>
Resultshttps://code.djangoproject.com/ticket/27234#changelog