Following code in mod_wsgi is wrong: if (*PyString_AsString(result) == '\0') { PyErr_SetObject(PyExc_StopIteration, Py_None); Py_DECREF(args); Py_DECREF(result); return 0; }
Meant to be checking length of string, not whether first character is a null. Thus: if (PyString_Size(result) == 0) { PyErr_SetObject(PyExc_StopIteration, Py_None); Py_DECREF(args); Py_DECREF(result); return 0; } It was done correctly in mod_wsgi 3.0 although code in that area had been changed around to handle Python 3.0 unicode strings. Not sure why I didn't notice that it was wrong and fix it in mod_wsgi 2.X. Anyway, the problem would affect mod_wsgi 2.0 and mod_wsgi 2.1 on Windows or Apache 1.3 on UNIX. Working version of mod_wsgi 2.2 which includes this and other fixes can be checked out from subversion at: https://modwsgi.googlecode.com/svn/branches/mod_wsgi-2.X More details in: http://code.google.com/p/modwsgi/wiki/ChangesInVersion0202 Haven't yet updated this with details of this fix yet though. Graham 2008/8/22 Simon J. Oliver <[EMAIL PROTECTED]>: > > Glad you're making some progress with it :-) > > As it happens. I'm using the macports python 2.5 on that that machine, > but that probably doesn't make any difference, given what you're > seeing. I am still using the 1.3.41 apache that came with Tiger, though. > > > Simon > > > > > > On Aug 21, 2008, at 8:50 PM, Graham Dumpleton wrote: > >> >> Duplicated using mod_wsgi 2.1 tar ball source code, Apache 1.3.41 and >> Python 2.3 as shipped with Tiger. Doesn't occur with Apache 2.2 >> though. >> >> With your file and test harness of: >> >> import os >> >> def application(environ, start_response): >> status = '200 OK' >> >> response_headers = [('Content-Type', 'text/plain'),] >> start_response(status, response_headers) >> >> path = os.path.join(os.path.dirname(__file__), 'null4k.txt') >> return environ['wsgi.file_wrapper'](open(path, 'rb'), 4096) >> >> Whatever is causing it, it is already fixed in mod_wsgi 3.0 >> development version as don't have the problem there. :-) >> >> Just need to work out what changed. >> >> Graham >> >> 2008/8/22 Graham Dumpleton <[EMAIL PROTECTED]>: >>> Ignore that, my test code below is somehow flawed. >>> >>> Even if I write a file containing 8192 null characters, can't >>> reproduce it. >>> >>> This is with Python 2.3, Apache 2.2.4 and MacOS X 10.4.11. >>> >>> And then something clicks. You are using Apache 1.3. For both Apache >>> 1.3 and Windows Apache 2.X, use of sendfile techniques isn't used and >>> so any problem would lie in mod_wsgi somewhere. I'll need to disable >>> the sendfile code manually and then see what happens. >>> >>> Graham >>> >>> 2008/8/22 Graham Dumpleton <[EMAIL PROTECTED]>: >>>> 2008/8/22 Simon J. Oliver <[EMAIL PROTECTED]>: >>>>> Thanks Graham! >>>>> >>>>> To save you the bother, I'm attaching said text file. This is the >>>>> one >>>>> with it aligned, so it breaks the download. >>>> >>>> Very odd. I have no problem with your file, but can trigger problems >>>> in other ways. Just the following is sufficient: >>>> >>>> def application(environ, start_response): >>>> status = '200 OK' >>>> >>>> response_headers = [('Content-Type', 'text/plain'),] >>>> start_response(status, response_headers) >>>> >>>> path = os.path.join('/tmp/null.txt') >>>> fd = open(path, 'w') >>>> #fd.write(8192*'\0') >>>> fd.write('\0') >>>> fd.seek(0) >>>> return environ['wsgi.file_wrapper'](fd) >>>> >>>> Doing HEAD using telnet get: >>>> >>>> $ telnet localhost 8224Trying ::1... >>>> Connected to localhost. >>>> Escape character is '^]'. >>>> HEAD /wsgi/scripts/file.py HTTP/1.0 >>>> >>>> HTTP/1.1 200 OK >>>> Date: Fri, 22 Aug 2008 00:57:38 GMT >>>> Server: Apache/2.2.4 (Unix) mod_wsgi/3.0-TRUNK Python/2.3.5 >>>> Content-Length: 1 >>>> Connection: close >>>> Content-Type: text/plain >>>> >>>> Connection closed by foreign host. >>>> >>>> If use curl it just hangs waiting for data. >>>> >>>> Don't even need 4k of data. The first character of any 4k block, >>>> including the first, being a null is possibly enough. >>>> >>>> I'll have to check the code path which is used, but the whole >>>> point of >>>> wsgi.file_wrapper is that it passes control for sending file off to >>>> Apache functions to do. So first impression would be that I can't >>>> see >>>> how this can be an issue in mod_wsgi and that it would have to be in >>>> Apache. >>>> >>>> Anyway, time for some digging. >>>> >>>> Graham >>>> >>>>> Cheers, >>>>> >>>>> Simon >>> >> >> > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to modwsgi@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en -~----------~----~----~----~------~----~------~--~---