You are viewing a plain text version of this content. The canonical link for it is here.
Posted to mod_python-dev@quetz.apache.org by "Graham Dumpleton (JIRA)" <ji...@apache.org> on 2005/03/28 11:04:18 UTC
[jira] Created: (MODPYTHON-41) Calls to PyErr_Print should be followed by fflush().
Calls to PyErr_Print should be followed by fflush().
----------------------------------------------------
Key: MODPYTHON-41
URL: http://issues.apache.org/jira/browse/MODPYTHON-41
Project: mod_python
Type: Improvement
Components: core
Versions: 3.1.4
Reporter: Graham Dumpleton
In mod_python.c there are a few places where PyErr_Print() is called. The output of this
function is sent to stderr and not to the Apache log functions. The output does make its
way into the Apache error log file eventually, but not straight away due to buffering
issues. In order to ensure the output gets the logs straight away, a call should be made
to fflush(stderr) after calling PyErr_Print(). Ie.,
PyErr_Print();
fflush(stderr);
This will ensure that relevant lower level Python errors appear adjacent to any error message
logged by mod_python to the error log file.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
Re: util.py - field attributes incorrectly set
Posted by Barry Pearce <ba...@copyrightwitness.net>.
Hi all,
Here is a new util.py based on the latest from subversion (attached).
Fixes:
1. Memory fault when streaming extremely large files to disk when
filename is sent from client.
2. Fixed headers being overwritten by headers for last field. Headers
are now available for all fields (assumed as original intention).
3. Fixed filename being overwritten by last file sent in multipart/mixed
posting with multiple files.
Enhancements:
1. Added file creation callback, allowing client to override both file
creation/deletion semantics and location - examples of ways to use this
are provided.
NOTE: This does not fix the issue of streaming to memory when no
filename is supplied by the browser.
---------------------
Examples for new file callback usage - 2 techniques are shown. The first
uses the class constructor to create the file object and uses simple
control. It is not advisable to add class variables to this if serving
multiple sites from apache - in this case to provide greater control
over the constructor parameters use the factory method. It should be
noted that the code shown here is used purely for example usage. The
issue of temporary file location and security must be considered when
providing such overrides with mod_python.
Both methods are common in that they derive from FileType. Thereby
providing extended file functionality.
Indeed. It is possible to subclass tempfile.TemporaryFile and gain the
same security semantics.
-----------------------------------------------------------------
Technique 1: Simple file control using class constructor.
from types import FileType
class Storage(FileType):
def __init__(self, advisoryFilename):
self.m_advisoryFilename = advisoryFilename
self.m_deleteOnClose = True
self.m_deletedAlready = False
self.m_realFilename = '/someTempDir/thingy-unique-thingy'
super(Storage, self).__init__(self.m_realFilename, 'w+b')
def close(self):
if self.m_deletedAlready:
return
super(Storage, self).close()
if self.m_deleteOnClose:
self.m_deletedAlready = True
os.remove(self.m_realFilename)
return
requestData = util.FieldStorage(request, True, file_callback = Storage)
-----------------------------------------------------------------
Technique 2: Advanced file control using object factory.
from types import FileType
class Storage(FileType):
def __init__(self, directory, advisoryFilename):
self.m_advisoryFilename = advisoryFilename
self.m_deleteOnClose = True
self.m_deletedAlready = False
self.m_realFilename = directory + '/thingy-unique-thingy'
super(Storage, self).__init__(self.m_realFilename, 'w+b')
def close(self):
if self.m_deletedAlready:
return
super(Storage, self).close()
if self.m_deleteOnClose:
self.m_deletedAlready = True
os.remove(self.m_realFilename)
return
class StorageFactory:
def __init__(self, directory):
self.m_dir = directory
def create(self, advisoryFilename):
return Storage(self.m_dir, advisoryFilename)
fileFactory = StorageFactory(someDirectory)
[...sometime later...]
requestData = util.FieldStorage(request, True, file_callback =
fileFactory.create)
-----------------------------------------------------------------
Hope this helps,
Barry Pearce
Re: util.py - field attributes incorrectly set
Posted by Nicolas Lehuen <ni...@gmail.com>.
Hi Barry,
First of all, the latest version is on the subversion repository found
at http://svn.apache.org/repos/asf/httpd/mod_python/trunk/ and not on
CVS.
You can send us your revised version of util.py on the list so that we
can compare with the current version and eventually check it in.
Regards,
Nicolas
On Mon, 28 Mar 2005 10:39:46 +0100, Barry Pearce
<ba...@copyrightwitness.net> wrote:
> Forget to mention..
>
> > The setting of filename and headers in Field at lines 46/47. This are
> > class variables not instance variables. Thus they are global to all
> > Field objects.
> >
> > This produces a number of issues:
> >
> > filename is set for ALL fields (lines 182-183). The software works but
> > only because of the code at lines 227, 272 and 286.
>
> This wont work correctly in forms which are sent as multipart/mixed with
> multiple files - it will claims the same filename for all files.
>
> Regards,
> Barry
>
Re: util.py - field attributes incorrectly set
Posted by Barry Pearce <ba...@copyrightwitness.net>.
Forget to mention..
> The setting of filename and headers in Field at lines 46/47. This are
> class variables not instance variables. Thus they are global to all
> Field objects.
>
> This produces a number of issues:
>
> filename is set for ALL fields (lines 182-183). The software works but
> only because of the code at lines 227, 272 and 286.
This wont work correctly in forms which are sent as multipart/mixed with
multiple files - it will claims the same filename for all files.
Regards,
Barry
util.py - field attributes incorrectly set
Posted by Barry Pearce <ba...@copyrightwitness.net>.
Hi all,
Delving into util.py further another couple of items have appeared. (i
now have the latest anon CVS of mod_python - v1.22 util.py)
The setting of filename and headers in Field at lines 46/47. This are
class variables not instance variables. Thus they are global to all
Field objects.
This produces a number of issues:
filename is set for ALL fields (lines 182-183). The software works but
only because of the code at lines 227, 272 and 286.
headers is set such that it only reflects the last set of headers. These
are not used internally in util.py but external software that choses to
use these will be mislead.
I have a fixed util.py based on 1.21 which corrects both of these issues.
How do I proceed from here? Anyone wish to see my changes?
Cheers,
Barry
[jira] Closed: (MODPYTHON-41) Calls to PyErr_Print should be
followed by fflush().
Posted by "Graham Dumpleton (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/MODPYTHON-41?page=all ]
Graham Dumpleton closed MODPYTHON-41:
-------------------------------------
> Calls to PyErr_Print should be followed by fflush().
> ----------------------------------------------------
>
> Key: MODPYTHON-41
> URL: http://issues.apache.org/jira/browse/MODPYTHON-41
> Project: mod_python
> Type: Improvement
> Components: core
> Versions: 3.1.4
> Reporter: Graham Dumpleton
> Assignee: Nicolas Lehuen
> Fix For: 3.2.7
>
> In mod_python.c there are a few places where PyErr_Print() is called. The output of this
> function is sent to stderr and not to the Apache log functions. The output does make its
> way into the Apache error log file eventually, but not straight away due to buffering
> issues. In order to ensure the output gets the logs straight away, a call should be made
> to fflush(stderr) after calling PyErr_Print(). Ie.,
> PyErr_Print();
> fflush(stderr);
> This will ensure that relevant lower level Python errors appear adjacent to any error message
> logged by mod_python to the error log file.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Resolved: (MODPYTHON-41) Calls to PyErr_Print should be followed by fflush().
Posted by "Nicolas Lehuen (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/MODPYTHON-41?page=all ]
Nicolas Lehuen resolved MODPYTHON-41:
-------------------------------------
Assign To: Nicolas Lehuen
Resolution: Fixed
Fix Version: 3.2.0
> Calls to PyErr_Print should be followed by fflush().
> ----------------------------------------------------
>
> Key: MODPYTHON-41
> URL: http://issues.apache.org/jira/browse/MODPYTHON-41
> Project: mod_python
> Type: Improvement
> Components: core
> Versions: 3.1.4
> Reporter: Graham Dumpleton
> Assignee: Nicolas Lehuen
> Fix For: 3.2.0
>
> In mod_python.c there are a few places where PyErr_Print() is called. The output of this
> function is sent to stderr and not to the Apache log functions. The output does make its
> way into the Apache error log file eventually, but not straight away due to buffering
> issues. In order to ensure the output gets the logs straight away, a call should be made
> to fflush(stderr) after calling PyErr_Print(). Ie.,
> PyErr_Print();
> fflush(stderr);
> This will ensure that relevant lower level Python errors appear adjacent to any error message
> logged by mod_python to the error log file.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira