Date: Mon, 17 Nov 1997 07:13 -0400
From: COAR@PROCESS.COM (Rodent of Unusual Size)
Message-Id: <009BD6B0BE5AD462.9931@PROCESS.COM>
To: new-httpd@apache.org
Subject: Re: expires header in bugdb
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org

>From the fingers of Dirk-Willem van Gulik flowed the following:
>
>Hmm, actually it was resizing and back/forward. And yes, I use netscape
>3... that should be broken enough. Originally I wanted to add a Last-
>Modifed; but I could not see a way of getting that out of the database,
>so I proposed a patch for an expiry of 30 minutes. (Which is about
>20 minutes more than it takes do download the page in switzerland
>around 13GMT :-)

    I'm sure Marc's pain on a reload is less than 10 minutes.  I hope.
    As I pointed out earlier, a Last-Modified based upon the database
    update time would be just ducky - as long as the DB didn't change
    whilst you were looking at stuff.  Otherwise, a change to some
    problem you *weren't* looking at - or even interested in - would
    force an undesired reload.

>Seems this needs one more itertation; as the form now also reloads
>itself; it could have a longer TTL. Any other cache pragma's one
>cann set ?

    I can modify the script to emit the Expires: header only on the
    table page instead of always; that's probably a good step anyway,
    since that's the one that requires the major reload and set-up.
    Maybe it would be best to have the 30M expiry on the search-results
    page, a virtually infinite expiry on the search form, and either no
    expiry or the actual PR Last-Modified for the full PR display.
    Those are fairly easily do-able..

    #ken    P-)}