[mod_python] Various simple questions. I hope.

Graham Dumpleton grahamd at dscpl.com.au
Sun Jan 29 17:27:12 EST 2006

Bart wrote ..
> Hey all.
> Question. When I write:
>     def requesthandler(req):
>         req.content_type = "text/plain"
>         req.write("Hello World!")
>         return apache.OK
> ...it returns "Hello World!0", so that style will
> corrupt particularly my non-HTML data, so I don't
> use it. Thing is, it's copy-pasted from 3.1(.3)
> documentation and I have 3.1.4 (-r1, in gentoo).
> So is this a difference between using AddHandler
> python-program and AddHandler mod_python?
> Or do the docs accidentally describe 3.2 or and old
> version?   (I use:
>   AddHandler mod_python .py
>   PythonHandler mod_python.publisher
>   PythonDebug On
> Is this unusual?)

Using PythonHandler to specify your own handler code is different
to specifying that mod_python.publisher be used. You are programming
in the style expected where you specify your own handler code but
are using mod_python.publisher as the dispatcher and thus why the
example you copied isn't yielding the expected results.

If using mod_python.publisher, you would write the above example as:

    def requesthandler(req):
        req.content_type = "text/plain"
        return "Hello World!"

Ie., the content of the page is returned as the result. You can still use
req.write(), but whatever is returned from the function will also be
appended and why you see the extra "0" at the end. That is the value
of apache.OK converted to a string.

> It also leaves me a little baffled on what I should
> return from a handler function. My code works,
> I just don't know whether it should be written
> the way it is.
> People discuss apache.OK, and the difference
> between it and apache.DONE and such, so I'm
> guessing this is current code - but apparently
> it works differently under publisher. Or my version.

If using mod_python.publisher you can largely ignore the apache.OK
and apache.DONE return statuses. Ie,. the main distinction is that for
your own handler you use req.write() and return statuses where as
if using mod_python.publisher the result of the function is the content
and you use exceptions to indicate status.

> It also left me confused about how to handle
> success and errors.
> It seems like you're suppose to return simple ones
> and raise things on specific errors when you want
> apache to use its error pages

You can say:

  raise apache.HTTP_SERVER_RETURN, apache.HTTP_NOT_FOUND

when using either your own explicit handler or when using
mod_python.publisher to indicate a specific status.

If using your own explicitly handler you can also do:

  return apache.HTTP_NOT_FOUND

In both cases, Apache will construct any page to go along with that
specific error response.

> but apparently
> you set req.status for other cses yet, because where
> does this leave things like the 304?
> I use  req.status=apache.HTTP_NOT_MODIFIED
> elsewhere to handle my manual ETags on
> dynamically served images. Despite me just having
> read that setting req.status doesn't actually do
> anything, my header snooper tells me it does in
> fact work. Reading somewhere else says it works,
> is the way it should work, and should probably be
> followed by a return apache.DONE.
> But since that doesn't seem to apply to me, what
> do I do? How do I get these apache.THINGS, since
> they seem to be the way thing work for other people?

If you want to override what page is sent back by Apache with a
specific error response, you would typically use something like:

  req.status = apache.HTTP_NOT_FOUND
  req.content_type = 'text/html'
  raise apache.HTTP_SERVER_RETURN, apache.DONE

or if using your own explicit handler, you could also say:

  req.status = apache.HTTP_NOT_FOUND
  req.content_type = 'text/html'
  return apache.DONE

The value apache.DONE is used instead of apache.OK as apache.DONE
tells Apache that you have constructed the complete response and that
it shouldn't go adding any page of its own for that status type.

> Am I just missing something obvious?

You are simple mixing two different dispatch mechanisms together and
the requirements it places on you as to how to write your published

> Also, because of the empty-string problem,
> I had to return something (I chose a space) instead of
> nothing, which I'm not sure is entirely up to HTTP specs
> since the RFC tells me "The 304 response MUST NOT
> contain a message-body"
> What's the better way of doing this?
> ("empty-string problem": Returning an empty string after
>   writing no data leads to borking out with 500/Internal Server
>   Error, and a "funtion x returned no data" error in the logs.
>   I'm guessing this is accepted, or at least expected behaviour,
>   though I'd prefer if that only happened on return None
>   (and implicitly on a lack of a return), but not on return "")

Fixed in mod_python 3.2.6. In mod_python.publisher in 3.2.6 it
will allow you return "" or None to represent nothing and it will
not raise a 500 error. If you do return these and there was no prior
output written, it will though log a warning message to the Apache
> So I suppose my real question is "Is there a nice overview
> of the varying behaviour under different versions and different
> PyhonHandlers, particularly the current?" Should I not be
> using the publisher, since it seems to contradict the docs?

It doesn't contradict the docs, as I said, you are mixing two different
ways of using mod_python together. You just need to read the
correct part of the docs.

> *If* I'm going to have to know a few innards to use mod_python
> so be it, but right now I have a fragile environment with
> no simple way of telling what'll work without testing it.
> And I don't like to bug you guys too much with this sort
> of "huh, what? wah!", y'know :)

We don't generally mind being bugged, especially like in your case
where it is obvious that you have done some homework to at least
try and understand the issue before posting. It is those where
it is obvious that they have not tried to work the problem out themselves
where it can get annoying after a while, especially where it is also a
bit off topic for the list. ;-)

Anyway, hope the above comments help.


More information about the Mod_python mailing list