Setting Last-Modified causes intermittent blank pages

[peterjanes]

I've been trying to write a plugin that sets the Last-Modified header for single posts. (Yes, I've read #2335; I don't have any dynamic content like sidebars on my individual post pages.) However, whenever I actually set the Last-Modified header the page becomes blank on every other reload; this also happens when users post comments on the page.

The code is pretty simple:

function lastmod() {

if( is_single() ) {

$modDate = mysql2date("D, d M Y H:i:s T",$wp_query->posts[0]->post_modified);
header("Last-Modified: $modDate");

}

}
add_action('wp_head','lastmod');

Environment is WordPress 2.0.2, PHP Version 5.1.2. In case it matters, the site on which this happens is hosted by DreamHost but is a manual install of WP.

[masquerade]

This is not a support forum, trac is for bugs in the actual WordPress code.

[peterjanes]

I understand that, @masquerade. The problem is explicitly not with the plugin code itself---which works in PHP itself, and which can set any other header (like Expires) when used in WordPress---but with the WordPress code itself causing completely empty (zero-length) pages to appear. The zero-length problem has been reported from time to time in trac (and on the forums) with few results; I've tracked down a reproducible symptom that may identify the ultimate shortcoming of the WordPress code that has caused these issues.

I did not enter this bug into trac on a whim. I looked through the entire WordPress codebase and trac database before entering this bug to try to determine the problem; I've hacked apart my WordPress install trying to debug the issue; and if I had a patch to provide I certainly would have.

To restate: to the best of my knowledge, WordPress is the cause of this problem, not the plugin code.

[masquerade]

a) You're not sending the headers are the proper time, as at the time of the wp_head hook content is already sent, init is a better choice. This would have been solved by asking at a support form, and with that change the code works fine.

b) That code is nowhere in the WP codebase, and WP would not stop sending output to the browser unless you caused errors, so no, WP is not at fault.

[peterjanes]

Thank you for the explanation. It remains a curiosity that any other header can be set in the wp_head action without causing this issue---perhaps a bug that WordPress allows that---but I accept that the better-supported hook is init.

As for your point b), obviously I'm very aware that the code I posted is not in the codebase, but as I stated it was my belief that it triggered (and still triggers) a bug in the WP code. Consider the messenger shot.

[masquerade]

Thank you for the explanation. It remains a curiosity that any other header can be set in the wp_head action without causing this issue---perhaps a bug that WordPress allows that---but I accept that the better-supported hook is init.

Not possible, please read ​http://php.net/header