simplecache plugin and RSS not modified header

[hanno]

I've been using the simplecache plugin for ages now and up until now never experienced any serious problem.

However I experienced something odd now: It seems that if you request the RSS feed with an If-modified-Since header it will *always* reply with "304 not modified".

Just a testcase:
$ curl -I -H "If-Modified-Since: Thu, 01 Jan 1970 00:00:00 +0000" https://s9y.hboeck.de/index.php?/feeds/index.rss2
HTTP/1.1 304 Not Modified
[...]

This disappeared when I disabled the simplecache plugin. I'm running s9y 1.7.8.

Anyone ever seen this before?

(I've just changed the URL to a test installation of mine where I could reproduce it with a minimal s9y installation. If you need backend access to test something please mail me and I'll send you credentials)

[garvinhicking]

Hm, the plugin was always more of a "proof of concept" that is good in specific scenarios, but has issues.

The logic is quite complex, and I believe the RSS feeds also have specific If-Modified handling. I'm afraid currently I don't have the time that would be needed for such a complicated issue to be resolved because there are other open issues with the 2.0 release that affect more commonly used areas.

If anyone is willing to have a go at this, I'd be happy to lend a hand or try to give feedback, but I can't really offer much help on this. Really sorry.

(I'd rather wanted to post this instead of not answering at all.)

[mattsches]

Hanno, I tried to debug the respective code a little, but did not dig too deep.

Yet I found something: It looks like there is a problem with your sending the equivalent of the unix timestamp 0. Well, actually not with your header, but with the code that tries to transform the date format into a unix timestamp.

Could you please try to request the feed with another date & time (e.g. …1971)? Do you still get a 304?

[mattsches]

Update: This should fix the issue. However, because the function is called quite often, I'm not sure if it has any (negative) side effects. Garvin?

Code: Select all

--- include/functions.inc.php	(revision bbf1456fd8240e922a88e0d60f4e3c968e30b4f9)
+++ include/functions.inc.php	(revision )
@@ -62,7 +62,7 @@
 function serendipity_serverOffsetHour($timestamp = null, $negative = false) {
     global $serendipity;
 
-    if ($timestamp == null) {
+    if ($timestamp === null) {
         $timestamp = time();
     }

PS: Tested against the latest 2.0 branch, but it's the same in master, I guess.
PPS: Boy, we sure need some unit tests

[garvinhicking]

Phew. Well. I honestly don't know. But I'd think that using === should be the actually expected behaviour, so I'd suggest you can commit it to the 2.0 branch. Better not port this to 1.x though.

Regards,
Garvin

[mattsches]

I'd suggest you can commit it to the 2.0 branch. Better not port this to 1.x though.

Exactly what I think.

I've just committed the fix, and I added a very basic unit testcase for it. You should be able to run it by

Code: Select all

$ cp tests/phpunit.xml.dist phpunit.xml
$ phpunit -c tests/phpunit.xml

Of course, the unit test stuff is open to discussion, but IMHO we have to begin with it sooner or later, so why not sooner

Mattsches

[hanno]

I've tested your patch on my blog and it seems alright. I re-enabled caching and behaviour is as expected.

Thanks a lot!