Save bandwidth by sending 304 Not-Modified?

[dand]

I tried subscribing to my own Serendipity blog http://danieldickison.com/blog/, and using NetNewsWire's activity viewer, I noticed that s9y always transmits the entire RSS feed with HTTP code 200 (OK). Most of the other feeds I subscribe to will reply with a 304 (Not Modified) header to save bandwidth.

My question is -- is s9y syndication capable of sending 304s, and if it is, what could be the problem with my setup that prevents them? My site is hosted by freepgs.com, so there are some restrictions in server services...

Daniel

[garvinhicking]

Hi!

Actually this SHOULD work! It's a feature of Serendipity sine the 0.8 versions.

Like here: http://blog.s9y.org/rss.php where it works. It doesn't on your blog, which I could see.

Are you running mod_php or PHP as CGI? Maybe the headers cannot be properly sent.

I don't know if it's already in s9y 1.0 (or 1.1), but we added a config option for "RFC2616" compliance in the "Appearance and Options" section. See if you have that, and to what you've set it?

It might be that your server is blocking header("HTTP/1.0 304") calls?!

Best regards,
Garvin

[dand]

I knew that there was no way s9y wouldn't have that feature already implemented

I'm running version 1.0 (or 1.0.1... not sure).
In the options, I have "Force XHTML 1.1 compliance" turned on. Is this the option you mentioned? It should be on, right?

I haven't been able to figure out yet if my hosting service is using mod_php or CGI -- I'll try posting to their forums to find out.

Thanks Garvin for your help. I'll report back if I find out anything new.

Daniel

[garvinhicking]

Hi!

No, the XHTML switch is a different one! Then it might be that the RFC-option is only in newer 1.1 versions. But that switch was only added to turn Conditional GET Cache OFF - it was turned to "ON" manually.

You might also want to just have a look into your rss.php. file; there you should see the place where the 304 header is emitted...

Best regards,
GArvin

[dand]

OK so it looks like all is fine with the server. A test PHP page I made sends 304s fine.

It appears that there is a bug in rss.php, on line 49:

Code: Select all

    $modified_since = !empty($_SERVER['HTTP_IF_MODIFIED_SINCE'])
                    ? gmdate('D, d M Y H:i:s \G\M\T', serendipity_serverOffsetHour(strtotime(stripslashes($_SERVER['HTTP_IF_MODIFIED_SINCE'])), true))
                    : false;

Since strtotime will parse the timezone specifier in the HTTP_IF_MODIFIED attribute (e.g. "GMT", "-0400", etc.) there is no need to call serendipity_serverOffsetHour on it. So that line should be:

Code: Select all

                    ? gmdate('D, d M Y H:i:s \G\M\T', strtotime(stripslashes($_SERVER['HTTP_IF_MODIFIED_SINCE'])), true)

Once I change that, it seems to be working as expected now. I suppose the reason it was working for you is because your server offset is zero?

It looks like there are some more problems with s9y's handling of time zones and the time offset setting in the options. I have a server offset specified in the configuration as +3 because the server is (apparently) in Pacific US Time, and I'm in Eastern US timezone. That means the server is GMT-0700, I am GMT-0400. In the RSS feed, the articles' pubDate shows the time in my timezone but it is mislabeled as -0700.

One more thing: it seems that most RSS feeds will send the last 15 or 20 entries even when the MODIFIED_SINCE attribute is sent. Some feed readers will only show the last 1 entry with Serendipity feeds because it "forgets" about the previous entries. I propose line 85 to be changed so that 15 entries are retrieved, ignoring the $modified_since variable:

Code: Select all

        $entries = serendipity_fetchEntries(null, true, 15, false, (isset($modified_since) ? $modified_since : false), 'timestamp DESC', '', false, true);
-----
        $entries = serendipity_fetchEntries(null, true, 15, false, false, 'timestamp DESC', '', false, true);

What do you think?

[garvinhicking]

Hi!

Thanks a lot for your help on this! It is much appreciated, because I admit that this timezone thing is not the easiest thing for me to grasp. I usually only deal with servers that are in the same timezone like me, so adding timezone-offset support was a hard thing to do for me.

Your patch to the rss.php file seems absolutely likely; i committed your fix to our SVN.

However, about the MODIFIED_SINEC thing: Exactly this is what was modified in 1.1 with the RFC-compliance option. If you turn it on, it will behave like now. If you turn it off, it will behave like the patch you made.

The reason why people may want to leave it on is because with that you can get the latest 70 or so entries after a specific time, like when you went on holiday. Else you would only get 15 feeds, thus missing 55 entries.

Best regards,
Garvin

[dand]

Glad to have helped! I get to use the software for free, so it feels good to be able to contribute something back, even if it's just a little.

However, about the MODIFIED_SINEC thing: Exactly this is what was modified in 1.1 with the RFC-compliance option. If you turn it on, it will behave like now. If you turn it off, it will behave like the patch you made.

The reason why people may want to leave it on is because with that you can get the latest 70 or so entries after a specific time, like when you went on holiday. Else you would only get 15 feeds, thus missing 55 entries.

It would be nice if it was MAX(15, {#posts since date}). As in, get all posts since MODIFIED_SINCE, but always get at least 15 entries. Is that how it's implemented in 1.1?

I would just update and check, but unfortunately I don't have shell access to my web hosting server so it's a bit of a pain to upload updates (since I can't simply unzip the archive to overwrite old files).

Daniel

[garvinhicking]

Hi!

Glad to have helped! I get to use the software for free, so it feels good to be able to contribute something back, even if it's just a little.

Exactly, many thanks for that. And it's nice to hear you enjoy Serendipity.

It would be nice if it was MAX(15, {#posts since date}). As in, get all posts since MODIFIED_SINCE, but always get at least 15 entries. Is that how it's implemented in 1.1?

No, in s9y you can then only switch between "Use #posts since date" or" "always use fixed number". It might be an idea to make a third option which uses your behaviour.

The problem with using a MAX... option would be that it wouldn't save bandwidth as neatly as the #posts_since option does.

Best regards,
Garvin