In a multithread MPM, the apache.init() function could be called
more than once for a specific interpreter instance whereas it should
only be called once. (MODPYTHON-150)
FieldStorage efficiency improvement provided by
Mike Looijmans.  Adapted FieldStorage documentation examples
from Barry Pearce.
(MODPYTHON-93)
Bumped version strings.
Moved where python_filter() accesses per request Python config to after the
request config object is acquired. Needed as way ap_internal_fast_redirect()
is used by Apache to implement DirectoryIndex was creating scenario where
per request config was null in parent request when accessed, causing a crash.
(MODPYTHON-103) (MODPYTHON-146)
When python_filter couldn't find an actual mod_python filter handler it was
returning DECLINED, but not releasing the interpreter. By rights this
scenario should never have happened, but issues caused by use of the
ap_internal_fast_redirect() function by Apache to implement DirectoryIndex
directive was causing it, as details of filters weren't being copied from
sub request object to parent. End result was further requests against that
interpreter in that process would hang as lock for interpreter couldn't be
acquired. Would also cause shutdown to hang with child processes needing to
be killed off forcibly by parent Apache process. (MODPYTHON-146)
The python_filter() function would only be called when Python*Filter is used
to register a filter and then Set*Filter or Add*Filter is used to trigger
the execution of that filter. Alternatively, it will be called when
req.register_*_filter() and req.add_*_filter() is used. In both cases
python_filter() should always be able to find a registered filter and if it
can't it is indicative of some sort of internal problem with Apache/mod_python.
This is the case with how ap_internal_fast_redirect() is used to implement
the DirectoryIndex directive with details of the handler for a mod_python
filter not being transfered from sub request to parent request. As such,
when a registered filter cannot be found it is really an error and so it
shouldn't be returning DECLINED but INTERNAL_SERVER_ERROR. Thus change code
to return an error and also log an explicit message indicating that a
registered filter couldn't be found. Note that even even if it were left to
return DECLINED in this case, Apache itself then in turn generates an
INTERNAL_SERVER_ERROR as no filter has properly executed, so the result is
no different, but having it return the error and log the message makes it
more explicit what is going on and the error log will indicate what the
problem is whereas Apache doesn't indicate what the problem is when it
generates the error making it hard for a user to work out what is going on.
Debug error page returned to client when an exception in a handler
occurred wasn't escaping special HTML characters in the traceback or
the details of the exception. (MODPYTHON-151)
Fixed indentation in example code for publisher doc.
Fixed more indentation issues in Doc/modpython6.tex code examples.
Fixes to test suite so it will work on virtual hosting environments
where localhost doesn't resolve to 127.0.0.1 but the actual IP address
of the host. (MODPYTHON-120) (MODPYTHON-121)
Note made in session documentation that a save is required to avoid
session timeouts. (MODPYTHON-111)
Added req.discard_request_body() function as wrapper for similar function
provided by Apache C API. The function tests for and reads any message body
in the request, simply discarding whatever it receives. (MODPYTHON-153)
The PythonImport directive makes use of the handler list data structure
even though it specifically is for a different purpose. The handler list
data structure needs to be changed a bit in order to support changes
required to address MODPYTHON-63 and MODPYTHON-126. These changes may
make it unusable in the way that the PythonImport directive was using it,
or at least it will not be a good match. The PythonImport directive has
therefore been modified to use a standard Apache table object thereby
allowing arbitrary changes to the handler list data structure to be made as
necessary.

Note that although the current Apache table implementation probably results
in module imports occuring in the order they appear in the Apache
configuration file, if how it is implemented is changed, this may no longer
be the case. This is not seen as an issue as the documentation for the
PythonImport directive does not give any guarantees about ordering of
imports within the context of a specific interpreter and it would be bad
practice for modules to rely on mod_python importing them in a specific
order. If there are ordering requirements, it should be dealt with internal
to the module being imported so that it is self contained.
A variable of type hl_entry was being used to copy pointer values of type
py_handler. Because of void* casting the code still worked fine, but the
mixing of pointer types could make someone looking at the code think
input/output filter lists held a data type different to what they actually
are.
Cleanup handler was calling free() on memory which was allocated from Apache
memory pool. The code was on an error handling path which would never normally
be executed and so wasn't causing any problems.
Fixed various constness and other pointer typing issues to eliminate warnings
generated by compiler.
Wrong interpreter name used for fixup handler phase and earlier, when
PythonInterpPerDirectory was enabled and request was against a directory
but client didn't provide the trailing slash. (MODPYTHON-157)
Added additional debugging and logging output for where mod_python cannot
initialise itself properly due to Python or mod_python version mismatches
or missing Python module code files. (MODPYTHON-158)
Added the value of the "__file__" attribute from "mod_python" module to
the error log output when there are problems executing "apache.init()" to
construct callback object. (MODPYTHON-158)
Minor documentation fix related to MODPYTHON-145.