Enhanced WSGI support for Django applications.
Django request handler which uses our enhanced WSGI request class.
Django-based response class which keeps the HTTP status reason phrase.
The original implementation in Django simply keeps the status code and does not allow developers to use custom HTTP status reason phrase, which is explicitly allowed by the HTTP specification: http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html
Bases: django.core.handlers.wsgi.WSGIRequest, webob.request.Request
Pythonic proxy for the WSGI environment.
This class is the Django request extended by WebOb’s request. Where they both have the same members, Django’s take precedence. For example, .GET uses django.core.handlers.wsgi.WSGIRequest.GET instead of webob.Request.GET.
To access WebOb’s GET and POST dictionaries, you have to use .uGET and .uPOST respectively.
Return a callable which can be used as a Django view powered by the wsgi_app.
|Parameter:||wsgi_app – The WSGI which will run the view.|
|Returns:||The view callable.|
Call the wsgi_app with request and return its response.
If path_info is not the last portion of the PATH_INFO in request.
The response from the WSGI application, turned into a Django response.
Exceptions raised by twod.wsgi.
Exception raised when an embedded WSGI application was not called properly.