Opened 9 years ago

Closed 9 years ago

Last modified 8 years ago

#14602 closed (fixed)

bug in wsgi handler in trunk

Reported by: Waldemar Kornewald Owned by: nobody
Component: Core (Other) Version: master
Severity: Keywords:
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


I get the following traceback with Django trunk:

  File "...\django\core\handlers\", line 251, in __call__
    request = self.request_class(environ)
  File "...\django\core\handlers\", line 137, in __init__
    if isinstance(self.environ['wsgi.input'], socket._fileobject):
TypeError: isinstance() arg 2 must be a class, type, or tuple of classes and types

When I changed the isinstance check to use .__class__ it worked, again.

Change History (10)

comment:1 Changed 9 years ago by Russell Keith-Magee

I don't see this error under the Django devserver, mod_wsgi, or the CherryPy devserver.

I'm going to guess this is happening on AppEngine?

comment:2 Changed 9 years ago by Waldemar Kornewald

Yes, you're right. I can only reproduce it on App Engine. Looks like they do something non-standard here.

comment:3 Changed 9 years ago by Russell Keith-Magee

Triage Stage: UnreviewedAccepted

Ok - in which case, you'll have to provide a patch that you can verify works. I don't have easy access to testing for AppEngine.

As a side note, I'd be interested to know what datatype socket._fileobject *is*, if it isn't a class or type.

comment:4 Changed 9 years ago by Waldemar Kornewald

Their servers and SDK emulate _fileobject as a function instead of a class. :(

If I understand the check correctly it's purpose is to check if we're running the development server, right? Is there some alternative method to do this cleanly?

comment:5 Changed 9 years ago by Russell Keith-Magee

You've understood the purpose of the check correctly; I can't think of an obvious alternative, other than providing a subclass of WSGIRequest that is used by the dev server and nothing else. Suggestions welcome.

comment:6 Changed 9 years ago by Waldemar Kornewald

As an alternative, the following patch makes it work on App Engine:

diff -r d45c568421e5 django/core/handlers/
--- a/django/core/handlers/      Tue Nov 02 13:58:12 2010 +0100
+++ b/django/core/handlers/      Tue Nov 02 14:57:24 2010 +0100
@@ -134,7 +134,8 @@
         self.META['SCRIPT_NAME'] = script_name
         self.method = environ['REQUEST_METHOD'].upper()
         self._post_parse_error = False
-        if isinstance(self.environ['wsgi.input'], socket._fileobject):
+        if type(socket._fileobject) is type and \
+                isinstance(self.environ['wsgi.input'], socket._fileobject):
             # Under development server 'wsgi.input' is an instance of
             # socket._fileobject which hangs indefinitely on reading bytes past
             # available count. To prevent this it's wrapped in LimitedStream

But this is just a workaround. Is this OK or should I try to fix this a custom WSGIHandler that has a custom WSGIRequest? Could that result in incompatibility issues with 3rd-party runserver alternatives? I'm not really familiar with this part of Django's code.

comment:7 Changed 9 years ago by Russell Keith-Magee

I suspect that this is more an issue with AppEngines curious sandbox implementation of the python standard library than with the WSGI wrapper itself. To that end, I'm happy to treat this as a workaround. Fix incoming.

comment:8 Changed 9 years ago by Russell Keith-Magee

Resolution: fixed
Status: newclosed

(In [14453]) Fixed #14602 -- Added an extra check to wsgi.input handling to prevent AppEngine from choking. Thanks to Waldemar Kornewald for the report.

comment:9 Changed 9 years ago by Waldemar Kornewald

Thanks a lot!

comment:10 Changed 8 years ago by Jacob

milestone: 1.3

Milestone 1.3 deleted

Note: See TracTickets for help on using tickets.
Back to Top