Make WordPress Core

Opened 19 years ago

Closed 19 years ago

#1275 closed defect (bug) (fixed)

RSS reports 304 Not Modified even if they have changed.

Reported by: admiraljustin's profile admiraljustin Owned by: matt's profile matt
Milestone: Priority: normal
Severity: major Version: 1.5.1
Component: XML-RPC Keywords:
Focuses: Cc:

Description

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.

Change History (15)

#1 @admiraljustin
19 years ago

  • Patch set to No

#2 @admiraljustin
19 years ago

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

#3 @admiraljustin
19 years ago

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

#4 @admiraljustin
19 years ago

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

#5 @ryan
19 years ago

  • Severity changed from minor to major

#6 @anonymousbugger
19 years ago

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

admiraljustin, forgot to login

edited on: 04-25-05 19:42

#7 @mdawaffe
19 years ago

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

#8 @admiraljustin
19 years ago

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

#9 @ryan
19 years ago

  • Owner changed from anonymous to matt
  • Status changed from new to assigned

#10 @jesse
19 years ago

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";

#11 @matt
19 years ago

Checked in a possible fix, please confirm.

#12 @anonymousbugger
19 years ago

Works for me (FeedDemon on Win)

#14 @dougal
19 years ago

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

#15 @matt
19 years ago

  • fixed_in_version set to 1.5.1
  • Resolution changed from 10 to 20
  • Status changed from assigned to closed

Restored Dougal's working logic

Note: See TracTickets for help on using tickets.