Opened 5 years ago

Closed 5 years ago

Last modified 4 years ago

#14602 closed (fixed)

bug in wsgi handler in trunk

Reported by: wkornewald 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: UI/UX:

Description

I get the following traceback with Django trunk:

...
  File "...\django\core\handlers\wsgi.py", line 251, in __call__
    request = self.request_class(environ)
  File "...\django\core\handlers\wsgi.py", 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 5 years ago by russellm

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

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 5 years ago by wkornewald

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

comment:3 Changed 5 years ago by russellm

  • Triage Stage changed from Unreviewed to Accepted

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 5 years ago by wkornewald

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 5 years ago by russellm

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 5 years ago by wkornewald

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

diff -r d45c568421e5 django/core/handlers/wsgi.py
--- a/django/core/handlers/wsgi.py      Tue Nov 02 13:58:12 2010 +0100
+++ b/django/core/handlers/wsgi.py      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 5 years ago by russellm

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 5 years ago by russellm

  • Resolution set to fixed
  • Status changed from new to closed

(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 5 years ago by wkornewald

Thanks a lot!

comment:10 Changed 4 years ago by jacob

  • milestone 1.3 deleted

Milestone 1.3 deleted

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