Is there any interest in adding functionality that enables TBNL to automatically send a "304 Not Modified" in response to content that has not changed? For example, in the Java Servlet world, a servlet author can define getLastModified(). What does this buy the servlet author? Automatic client-side caching. For those not familiar with the "Last-Modified/If-Modified-Since" headers, here's a brief overview.
The first time client A visits our servlet page, our servlet is called to generate some HTML output. If a servlet author has implemented getLastModified(), the servlet container invokes this method and inserts a "Last-Modified" header in the response to the client. The value of this header is a date specifying when the page was last modified. This value is cached in the client's browser.
The next time client A visits our servlet page, in the HTTP request, the client's browser includes a "If-Modified-Since" header with the value that our servlet had previously sent. When our servlet receives the request, it notices the "If-Modified-Since" header, and thus invokes our servlet's getLastModified() method (if defined). When the time returned by this method is newer than the time the client sent, the servlet container proceeds to dispatch the request to our servlet for processing and generation of output.
Things are more interesting when the value returned from getLastModified() is the not newer than the value of the "If-Modified-Since" header. In this case, the servlet container bypasses our servlet and simply sends a "304 Not Modified" back to the client which instructs the browser to display the cached content. It is important to note that this servlet container did not dispatch to our code to generate HTML output, it is completely bypassed and all handled by the container.
This is the functionality that I would like to add to TBNL. I'm going to do it for myself even if its not part of the core; however, I thought it would be useful for others as well, and thus this post. How would one implement this within TBNL? Would the same approach the Java folks used suffice? Provide a special variable, *last-modified-handler*, that users can set to return a timestamp? From within that method, users would have access to *request* so they could return specific times for various URIs. This is what I need it for, my entire site will be served by HTML-TEMPLATEs and I'll use the last time the template file was modified as my timestamp.
Thoughts?
Thanks, Pete
On Tue, 13 Jul 2004 16:43:22 -0400, pete-tbnl-dev@kazmier.com wrote:
Provide a special variable, *last-modified-handler*, that users can set to return a timestamp? From within that method, users would have access to *request* so they could return specific times for various URIs.
Sounds like a good idea to me. The initial value of this special variable should probably be (CONSTANTLY NIL) where NIL returned by the handler means that it declines to provide a timestamp - which would be equivalent to returning (GET-UNIVERSAL-TIME). The handlers should generally return universal-times, of course.
Something like that. Would you like to send a patch?
This is what I need it for, my entire site will be served by HTML-TEMPLATEs and I'll use the last time the template file was modified as my timestamp.
But even if the template itself hasn't changed you might fill the template with different values each time it is called, isn't that the whole purpose of HTML-TEMPLATE? Or am I missing something?
Cheers, Edi.