Have started to have a look through the latest mod_python.publisher
code, got a few comments to make about it.
First is that it has been changed to allow "HEAD" requests whereas
before it only supported "GET" and "POST". A "HEAD" request is handled
by the mod_python.publisher code saying:
if req.method!='HEAD':
req.write(result)
That is, it is supposed to work by detecting the "HEAD" request and
not actually writing back the result in that case.
This solution though ignores the fact that even with
mod_python.publisher
one can explicitly use the "req" object to write back data. Ie.,
def method(req):
req.content_type = "text/plain"
req.write("data-1\n")
return "data-2\n"
In this case, for a "HEAD" request, one will still get "data-1" sent
back
but "data-2" will not.
I guess the question I have is whether it is worthwhile supporting
"HEAD"
in the first place with mod_python.publisher? What does one actually
gain,
especially when it will not strictly work in all situations?
Second issue is the fact that new mod_python.publisher code uses the
req.finfo attribute. This may be convenient, but it prevents some cute
stuff being done in the future.
It is all about a vision I have of being able to implement middleware
like handler components for mod_python much as WSGI is attempting. In
this case we can use the full power of Apache and mod_python whereas
WSGI is restricted to its minimal server API.
The first thing that really needs to be done to achieve a similar thing
in mod_python is to make req.path_info writable. When this is added to
the fact that req.filename is already writable, it would allow a
middleware
component to setup both req.filename and req.path_info and then trigger
existing mod_python handlers such as mod_python.publisher.handler() to
serve up the request based on these values.
A big benefit of this is that you can put all your web application
Python
code outside of your document tree with just a little middleware stack
within the document tree defining the delegation to the external code.
If someone screws up your Apache configuration and exposes your files,
all that is exposed is the minimal bit of code which performs the
delegation.
Another benefit of modelling stuff as middleware, including wrappers
around existing handlers such as publisher and PSP, is that it becomes
easier to mix use of different mechanisms in a more flexible way without
having to resort to gymnastics in the Apache configuration.
For this sort of thing to work, the middleware component will be what
maps the URL against the external directory and sets up req.filename and
req.path_info as appropriate. Ie., this would no longer be done by
Apache and thus the value of req.finfo is never set to a usable value.
That mod_python.publisher relies on req.finfo means that this sort of
thing may not be practical to do, which would be disappointing. :-(
I realise that people may not understand where I am going with this and
it may be a personal crusade of mine, but have been real busy of late
and haven't had a chance to get my code suitable for general
consumption.
A final issue, is that latest mod_python.publisher no longer pays
attention to result of req.get_addhandler_exts(). This means that where
you used to be able to say:
# .htaccess
AddHandler mod_python .html
PythonHandler mod_python.publisher
# page.py
def index():
return "<html></body><p>XXX</p></body></html>"
with URL of "/page.html", this no longer appears to work for me. In
short it appears that one can only use ".py" as an extension or no
extension at all. Defining another extension to AddHandler or
PythonHandler seems to have no effect.
I'll post about anything else I find another time.
Graham
