I've read through the documentation. I like the interface - just call ap_update_mtime for every object your response depends on (and another great feature: It starts with the mtime of the file, so that updates to the script also invalidate the cached response).

Exposing those three functions would make a very good addition. A little Pythonic wrapping around ap_update_mtime to accept reasonable things like datetime objects would be helpful.

ap_discard_request_body() might help resolving the issue with HEAD request writing out a body, maybe that change was related to http://issues.apache.org/jira/browse/MODPYTHON-71 but I'm not sure.

Mike Looijmans
Philips Natlab / Topic Automation


Graham Dumpleton wrote:
Mike, I have a feeling that Apache has ways of generating those date/time
strings for last modified for you. Thus, the routine shouldn't be required.
The real problem is that mod_python doesn't expose the methods which
may actually be useful to you.

Can you look through the Apache functions described in:

  http://162.105.203.19/apache-doc/138.htm

and indicate whether if functions like:

  ap_set_etag()
  ap_update_mtime()
  ap_set_last_modified()

you could more easily do the same thing.

The request object already provides equivalent to ap_meets_conditions(),
but not these others.

I also find the function:

  ap_discard_request_body()

to be interesting. That might be interesting to have access to as well.

Graham

Mike Looijmans wrote ..

We probably want to defer until after 3.2.7 (final) is released to have
any serious discussion about what should constitute version 3.3, but
am still curious to know at this point where your interests in 3.3 lie.
Is it simply to help finish up eliminating all these known issues/bugs
or do you have other ideas in mind as to the direction of mod_python?

Well, since you asked...

I'd like to see more HTTP level helper functions. For one thing, I keep
writing the same stuff for handling if-modified-since headers, accept,
and similar construct. Having one library to handle these with would be
very helpful.

For example, a function to format a datetime tuple into a HTTP style
date string (this one should *definitely* go into mod_python), as well
as its counterpart. Note that this implementation is not correct as it
does not handle timezones...

##

weekdayname = ('Mon', 'Tue', 'Wed', 'Thu', 'Fri', 'Sat', 'Sun')

monthname = (None,
             'Jan', 'Feb', 'Mar', 'Apr', 'May', 'Jun',
             'Jul', 'Aug', 'Sep', 'Oct', 'Nov', 'Dec')

def httpdate(dt):
    """Return the current date and time formatted for a
    message header."""
    now = time.time()
    year, month, day, hh, mm, ss, wd, y, z = dt
    s = "%s, %02d %3s %4d %02d:%02d:%02d GMT" % (
            weekdayname[wd],
            day, monthname[month], year,
            hh, mm, ss)
    return s

##

Another thing I use very often (when writing DB apps) is the
if-modified-since mechanism. This helps reducing the load on the server
since most clients will be visiting the same page a number of times in
a
session.
Calling checkLastModified in my code quickly aborts rendering the page
if it hasn't changed since the last visit.
(This one is incomplete as well - should add support for etag and length
extensions. The etag is very useful when things like username can change
between pages.)

##

def checkLastModified(req, lastmod):
    """If lastmod is non-zero (should be datetime object), outputs
    a Last-Modified header. If the browser supplied an identical
    If-Modified-Since header, this method raises
    apache.SERVER_RETURN with apache.HTTP_NOT_MODIFIED
    which informs the browser to use its cached version.
    """
    if lastmod:
        ifmodsince = req.headers_in.get('if-modified-since', None)
        strlastmod = httpdate(lastmod.timetuple())
        if ifmodsince:
            # TODO: We might want to do <= i.s.o. ==
            if strlastmod == ifmodsince:
                raise apache.SERVER_RETURN, apache.HTTP_NOT_MODIFIED
        req.headers_out.add('Last-Modified', strlastmod)

(note to self: Learn to hit "Reply All" instead of just "Reply"
--
Mike Looijmans
Philips Natlab / Topic Automation

Reply via email to