#14602 closed (fixed)
bug in wsgi handler in trunk
Reported by: | Waldemar Kornewald | Owned by: | nobody |
---|---|---|---|
Component: | Core (Other) | Version: | dev |
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 |
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 by , 14 years ago
comment:2 by , 14 years ago
Yes, you're right. I can only reproduce it on App Engine. Looks like they do something non-standard here.
comment:3 by , 14 years ago
Triage Stage: | Unreviewed → 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 by , 14 years ago
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 by , 14 years ago
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 by , 14 years ago
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 by , 14 years ago
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 by , 14 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
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?