Much concern, hand wringing and advice on RSS bandwidth issues lately. (see Regular Sucking Schedule, and HowTo RSS Feed State). Here’s some more.

skipHours (and co.), ttl, and mod_syndication are all considered harmful. They’re all under specified, highly ambiguous, poorly supported, poorly implemented, and move logic into the file which should be (and is) in the protocol. Rule of thumb, if your bandwidth saving mechanism is in your feed, it’s a mistake. They promise false hopes of salvation, ignore them.

HTTP Will Save You

Rather look to: - Conditional GET, learn it, live it, love it. Trivial to support, you have my permission to ban clients which don’t support it.

  • GZIP encoding, the obvious solution to bandwidth concerns is to swap a little CPU (and the magic of HTTP caching really does minimize it), for a whole lot of bandwidth savings. Been looking for a reason to upgrade to Apache 2.0? How about moddeflate is included by default and is more stable then the arcane (and nomadic) modgzip (which was a beacon a in the darkness in its day)
  • RFC 3229 aka HTTP deltas, and modspeedyfeed (reason #2 for upgrading Apache 2.0). Wave of the future, next puncture in the equilibrium, Sam has some notes: Varg ETag, Syndication with RFC3229, RFC3229 enabled, modspeedyfeed.

It’s All About Apache2 and HTTP/1.1

This post also does double duty as the my weighing in on Apache2 vs PHP mini- controversy### Fat Media

Obviously none of this will save you from the bandwidth concern of podcasting (or videoblogging!). I’m willing concede that those concerns are beyond the scope of basic HTTP, and point your attention to BitTorrent.