To all three of you reading this via LiveJournal syndication, sorry for filling up your friends list with repeats. I changed the footer on the feed, and didn’t realize that LiveJournal will repost articles as new if there’s any change.

I guess this means I’ll have to be careful about things like fixing typos on the latest 15 posts.

Does anyone know how to convince Google to prefer an HTML page over an RSS feed when serving standard search results?

With the demise of the Jamie Jack and Stench show, Another One Bites the Dust has shot back up to the top 5 pages on the site. It turns out it’s the #7 hit on Google for “jamie jack and stench.” Oddly, the comments feed for Alternative to Music? is #8. Not the post itself, which includes all the same comments, but the feed.

I don’t want to keep the feeds out of Google’s index — if someone’s looking for feeds, and mine happen to be relevant, I want them to show up. But if someone’s looking for web pages, shouldn’t Google bring up the web page with substantially similar content in favor of the feed?

Upgraded to WordPress 2.0.6 and now feeds are broken. At least, they’re broken in Firefox, IE7, and KDE (Konqueror & Akregator). Something seems to be interrupting the transfer, causing them to get a blank file. Oddly, they work fine in Opera, the LWP “GET” command-line utility, and Dillo (not that Dillo can do anything but display the source, but it gets the whole file.) Even more oddly, SeaMonkey seems to have no problems. You’d think Firefox and SeaMonkey would have the same issues. Also, I seem to be able to sometimes get it to work on reload.

Anyway, I’m working on it. If you read this site via RSS or Atom, and it is working, let me know (and let me know which feed reader you’re using). I suppose it could be cookie-related, though I’ve already tried clearing cookies. I’ve also tried disabling just about every plugin I use that does something to feeds or headers, to no avail.

Update: I think I’ve got it. By using the Tamper Data extension, I was able to determine that the 304 Not Modified status was not being set properly. Instead of actually issuing the 304 status, it would issue a 200 OK, then send a Status: 304 header later in the response. It never showed any problems on command-line GET or HEAD because they weren’t conditional. That’s also why forcing reload would work.

I looked into wp-includes/functions.php and found the status_header function. Then I looked at the following line:

@header("Status: $header $text");

In theory this should work. Traditionally, setting a “Status” header will replace the actual HTTP status. But that’s not how the PHP manual says to do it. They suggest issuing the actual header that the server would send: HTTP/1.1 304 Not Modified. I noticed that the header function in PHP has some optional parameters, including one to force the HTTP status. That felt a little cleaner than hard-coding the protocol (since an older browser might make an HTTP/1.0 request, and it should get an HTTP/1.0 response), so I changed the line to this:

@header("Status: $header $text", TRUE, $header);

It seems to have fixed the problem.

For the record, this is PHP 5.2.0 on Apache 1.3.37 using the mod_php interface.

Update 2: Simpler fix just removes the if.. statement and else… section so that it’s just the following:

@header("HTTP/1.1 $header $text");

Bug reported as Ticket 3528.

Continue reading

Well, Firefox 2 beta 1 is out, and I’ve been trying it out. I used to run nightly builds back in the early days, but since 1.0 hit, I haven’t been willing to go below beta-level for my primary browser, so I haven’t really been following development of Firefox 2. (Let me just say I really like in-line spell checking!)

As a web developer, one of the new features that caught my eye is microsummaries. If the name weren’t already taken, “live bookmarks” would have been the perfect description.

Basically it retrieves info from the bookmarked page and updates the label on your bookmark. Examples given include the current price and remaining time for an auction, or current stock price, or weather data. The page author can describe what chunk of data to use, or you can write an installable “generator” that applies itself to some list of pages.

This is a pretty cool idea: basically a 1-item RSS feed, automatically generated from the current page. (The disadvantage is that the browser retrieves the full page and then extracts the data, whereas an RSS feed is already summarized.) Edit: Apparently it’s also possible to link to a 1-line text document instead.

So, being handed a new tool, I immediately started trying to come up with something to do with it.

And came up more-or-less empty.

There are only two areas on my site that I update regularly: Flash: Those Who Ride the Lightning and this blog—and both are more suited to the list of recent updates that you get with RSS or Atom than the latest-info-only that you get with a microsummary.

It might prove useful for server monitoring, though. Condense the important info from a report (like “No alerts” vs “Server X down!”) and put it on the browser toolbar.