Many people who are on hosting plans that offer terabytes of bandwidth may not care, but WordPress feeds suck up a lot of bandwidth. This is bad news for people like me who are charged by the byte, but it’s possible to reduce bandwidth consumption on feeds with a quick hack.

In theory, WordPress receives If-modified-since and If-none-match headers, processes them, and responds with an appropriate 200 OK or 304 Not Modified header. Bandwidth would be saved if it matches 304 Not Modified because the content wouldn’t be sent. However, in practice, WordPress does not correctly process the If-none-match header due to some PHP and WordPress weirdness. That means content is sent with a 200 OK header no matter what.

One solution would be to not send the ETag header at all. This would work with some feed readers such as Firefox’s Live Bookmarks feature. The drawback is that it wouldn’t work with feed syndicators such as Bloglines and Facebook because they check both the Last-modified and the ETag headers.

The other, preferred solution is to fix the processing of If-none-match headers with a quick and easy hack. In WordPress 2.0.5, open up wp-includes/classes.php and go to line 1640. Replace if (isset($_SERVER['HTTP_IF_NONE_MATCH'])) $client_etag = stripslashes($_SERVER['HTTP_IF_NONE_MATCH']); with if (isset($_SERVER['HTTP_IF_NONE_MATCH'])) $client_etag = stripslashes(stripslashes($_SERVER['HTTP_IF_NONE_MATCH'])); Now your bandwidth usage for WordPress feeds should be reduced. Don’t forget that you’ll have to do this every time you upgrade WordPress.

Update: It seems that they have applied this patch for the ETag bug for release in WordPress 2.1. Users of 2.0.x will still have to manually apply it.