I know I'm very late coming back to this thread, but just wanted to
report that your fix did indeed resolve the original issue on Windows
as well - using mod_wsgi 2.3 file transfers are now working perfectly.
Nice work!
Matt
On Aug 21, 10:06 pm, "Graham Dumpleton" <[EMAIL PROTECTED]>
wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
