2008/8/22 Simon J. Oliver <[EMAIL PROTECTED]>:
>
> Graham -
>
> Thank you so much. I downloaded 2.2 and it does indeed seem to have
> fixed the problem.
>
> I appreciate the prompt attention to this issue.
It always helps when people can give a good pointer, like you did, as
to what the problem is and are also happy to do a bit of debugging if
I have further questions. There have been separate cases in the past
where people have indicated they were having a problem but did little
to debug it themselves nor were they supplying the exact information I
needed when I asked various questions. In one case person came out and
said I was being too difficult when I kept asking questions.
So, it gets frustrating sometimes, but generally more than happy to
help sort problems out, especially when it is a problem in mod_wsgi
code itself. :-)
BTW, since I haven't heard any complaints about other fixes pending
there in 2.2 and haven't had time to investigate further some of the
graceful shutdown issues, I'll try and roll out a version 2.2 now.
I know there are some other potentially worrying issues outstanding at
the moment, but don't have simple answers for those now, plus haven't
had a huge amount of time lately to work on it.
Graham
> Simon
>
>
>
>
>
> On Aug 21, 2008, at 10:12 PM, Graham Dumpleton wrote:
>
>>
>> On Apache 2.X on UNIX, you would also have had problems if file like
>> object supplied to wsgi.file_wrapper wasn't actually an open file with
>> associated file descriptor, but some other file like object. For
>> example:
>>
>> import StringIO
>> data = StringIO.StringIO(8192*'\0')
>> return environ['wsgi.file_wrapper'](data, 4096)
>>
>> Graham
>>
>> 2008/8/22 Graham Dumpleton <[EMAIL PROTECTED]>:
>>> 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 [email protected]
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
-~----------~----~----~----~------~----~------~--~---
