r1622-1626: lastmod

zem · 2006-08-06 01:51:25

if-modified-since support is enabled by default as of r1626. It’ll need some testing. Couple of things to be aware of:

you can turn it off with the ‘send lastmod’ advanced pref
it’s only active in Live mode

Also, there’s some weird behaviour on Textdrive where an empty deflate header is sent after a 304 response. It seems to be caused by mod_deflate, not Textpattern or PHP. As far as I can tell it’s harmless as long as we send ‘Connection:close’.

wet · 2006-08-06 10:19:00

IMHO, you should avoid returning 304 for requests containing a non-TXP query parameter (as used by various plugins like bas_locate_me or upm_image), as you have no control over the results of that query. So www.domain.com/?foo=bar should always travel whole circle, while www.domain.com/?s=about can take a shortcut route.

zem · 2006-08-06 11:37:54

Can you give an example of how that might cause a problem?

wet · 2006-08-06 13:58:55

Various examples come to mind:

Imagine a webcam plugin reading the desired cam location and giving an image: www.domain.com/?cam=Rome
Imagine a shop plugin, stock list is read from an external database table. www.domain.com/?artno=12345, and a subsequent price change in the external database.

Both cases (and various others) will return 304 upon second invocation, as long as the site’s content and presentation remain unchanged.

Mary · 2006-08-06 15:04:33

…as long as the site’s content and presentation remain unchanged.

So… what would the problem be?

Last edited by Mary (2006-08-06 15:04:46)

wet · 2006-08-06 16:37:50

If I properly understand Alex’ logic, 304 is sent when $prefs['lastmod'] is chronologically earlier than $SERVER['HTTP_IF_MODIFIED_SINCE'], i.e. the user agent has a current version of the site as far as txp is aware of the site’s content.

$prefs['lastmod'] is updated when a modification of these txp items occurs:

page template
form
article
style sheet
link
section

I haven’t found any instances of update_lastmod() in txp_discuss.php though I think there’s a need for it, as publish/comments.php contains this line (not using update_lastmod())

#331: safe_update("txp_prefs", "val=now()", "name='lastmod'");

Changes in the expected HTML stemming from any other source (for instance any plugins using external data to build parts of the server’s reply) will not result in the delivery of fresh content. This could be anything ranging from the hypothetical examples I gave above, to the ubiquitious flickr/del.icio.us/digg plugins, to plugins delivering a “random quote of the day” / random header image per invocation / etc…

One sign of such a thing happening is the presence of a custom query parameter which leads to the reason of my original post. Other sources of an improper 304 response might exist elsewhere.

At least this is what I have understood from the code…

Last edited by wet (2006-08-06 16:40:12)

zem · 2006-08-06 22:34:39

One sign of such a thing happening is the presence of a custom query parameter which leads to the reason of my original post.

I’d say there’s pretty much no correlation between query string parameters, and whether or not the page content is changeable. (If you’re thinking of things like article paging: when the query string changes, the browser will consider it a different URL, and hence won’t send an if-modified-since request). It’s also not as simple as checking for a “custom query parameter” – query string parameters are different in different contexts (think article list, individual article, image gallery – ‘pg’ is a Textpattern parameter on an article list page, but not an individual article or gallery page).

There are already a few ways plugins can conditionally disable caching: by sending a Cache-control header; by changing the value of $prefs[‘send_lastmod’]; and by calling update_lastmod(). Seems to be that formalizing one or more of those is a better solution.

Also: not sending fresh content for every single pageview is not necessarily a bad thing, even when ‘live’ or random tags are used.

Last edited by zem (2006-08-06 23:31:36)

wet · 2006-08-07 06:26:28

zem wrote:

Seems to be that formalizing one or more of those is a better solution.

Ack.

Last edited by wet (2006-08-07 06:26:43)

wet · 2006-08-14 10:21:20

@zem:

handle_lastmod() is apparently called from publish.php before a frontend plugin providing custom tags (random quote, article expiry, and similar) is invoked, and exits upon detecting a 304 condition. How can a plugin modify the last updated time of the site when an article embedding said plugin tag is never rendered? Plugins might depend on a specific article’s context to determine their last-mod date, I suppose, so a global hook / callback wouldn’t suffice.

zem · 2006-08-14 22:37:05

Off the top of my head:

At plugin load time, set $GLOBALS['prefs']['send_lastmod'] = 0;. Later, when you’ve determined the lastmod date, set it back to 1 and call handle_lastmod($newlastmod).

I’m happy to add a simpler solution if you can suggest one.

Textpattern CMS

Textpattern CMS support forum

#1 2006-08-06 01:51:25

r1622-1626: lastmod

#2 2006-08-06 10:19:00

Re: r1622-1626: lastmod

#3 2006-08-06 11:37:54

Re: r1622-1626: lastmod

#4 2006-08-06 13:58:55

Re: r1622-1626: lastmod

#5 2006-08-06 15:04:33

Re: r1622-1626: lastmod

#6 2006-08-06 16:37:50

Re: r1622-1626: lastmod

#7 2006-08-06 22:34:39

Re: r1622-1626: lastmod

#8 2006-08-07 06:26:28

Re: r1622-1626: lastmod

#9 2006-08-14 10:21:20

Re: r1622-1626: lastmod

#10 2006-08-14 22:37:05

Re: r1622-1626: lastmod

Board footer