RSS reports 304 Not Modified even if they have changed.

[admiraljustin]

The feeds on my weblog are reporting 304 to all requests, even if the data in the feed has changed.

Reproducable.

No server configuration has changed.

Tested ways to access feed that have failed:
Bloglines (does not notice update, currently 1 post behind)
SharpReader (3 posts behind)
Loading XML into FireFox browser window, can be corrected doing a cache-bypass reload (ctrl+f5)

The Sage extension for FireFox does retrieve the feed correctly, but this may be due to failure to recognize the 304.

[admiraljustin]

Oh, currently using the 4-22 nightly, problem first noticed in 4-17 build.

[admiraljustin]

Header Log:
GET /feed/ HTTP/1.1
Host: www.admiraljustin.net
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
If-Modified-Since: Fri, 22 Apr 2005 13:19:01 GMT
If-None-Match: "68f570b395c69da916504d5da3c98851"
Cache-Control: max-age=0

HTTP/1.x 304 Not Modified
Date: Fri, 22 Apr 2005 17:58:40 GMT
Server: Apache/1.3.29 (Unix)
Etag: "de8e000af8fddd71455801d354352cca"
X-Pingback: ​http://www.admiraljustin.net/xmlrpc.php
X-Powered-By: PHP/4.3.10
Last-Modified: Fri, 22 Apr 2005 13:38:46 GMT
Keep-Alive: timeout=2, max=200
Connection: Keep-Alive
Content-Type: text/html

[admiraljustin]

Has been reproduced on other domains, suggest raising priority to major or blocking.

[anonymousbugger]

Tracked down to changes in changeset 2534, rolling back to 2529 works.

^{admiraljustin, forgot to login}

edited on: 04-25-05 19:42

[mdawaffe]

Changing the

to an && on line 137 of the latest SVN produces the correct 200 v. 304 behavior, as far as I can tell. I'm not sure that the logic is perfect, though; I'm unfamiliar with HTTP_IF_NONE_MATCH and therefore don't know what the ${X}_etag variables are.

EDIT:
The (edited) line in question is
if ( (strtotime($client_last_modified) <= strtotime($wp_last_modified)) && ($client_etag == $wp_etag) ) {

edited on: 04-25-05 19:41

[admiraljustin]

HTTP_IF_NONE_MATCH is another possible header, and etags are md5's of the host/date stuff.

[jesse]

IMHO, the "<=" should be ">=". We should only reply 304 when the HTTP_IF_MODIFIED_SINCE is newer or equal to $wp_last_modified.

--- wp-blog-header.php
+++ wp-blog-header.php
@@ -134,7 +134,7 @@

else $client_etag = false;

if ( $client_last_modified && $client_etag ) {

if ( (strtotime($client_last_modified) <= strtotime($wp_last_modified)) + if ( (strtotime($client_last_modified) >= strtotime($wp_last_modified))

($client_etag == $wp_etag) ) {

($client_etag == $wp_etag) ) {

if ( preg_match('/cgi/',php_sapi_name()) ) {

header('Status: 304 Not Modified');
echo "\r\n\r\n";

[matt]

Checked in a possible fix, please confirm.

[anonymousbugger]

Works for me (FeedDemon on Win)

[admiraljustin]

Works.

[dougal]

This logic still isn't complete. It only handles the case where both the If-Modified-Since *and* the If-None-Match (ETag) headers are present. But the spec allows for a case where only one (either one) of the headers is present.

If only one of them is present, then it must satisfy its condition in order to return a 304: either If-Modified-Since is >= the web content's modify date, OR the If-None-Match is equal to what the server thinks the ETag should be.

If both are present, then both conditions must be true (which is all we're checking right now).

We need to put back in support for the case where only one of the headers are present, or we'll be missing some 304 opportunities, and wasting bandwidth.

edited on: 05-05-05 13:52

edited on: 05-05-05 13:52

[matt]

Restored Dougal's working logic