I could not understand what was going on. My code was basically structured like this:

Given that code, we know the req object is initialized with each function call. So, how could this script degrade over time?

Well, I finally tracked it down: COOKIES!

Yup, request has cookies enabled by default. So, I think what was happening was that cookies were being set (presumably, top domain-level cookies having the same name at different URLs or subdomains on the same domain) but the values in request's cookie jar were not being returned properly. That means the remote host was getting invalid cookies -- hence the 400 response for a "Bad Request."

I haven't yet spent the time to figure out if this is a bug in request. It's on my TODO list.

In the meantime, I've disabled cookies in the req object:
var req = { url: url, timeout: options.timeout, jar: false };

It's now working as expected.

One of the things I love about River2 is that it's an app that runs in the OPML Editor, which means that it is endlessly hackable and (apropos to this post) you can fix your own bugs.

So here's a bug report. And fix. (Actually, it could be a workaround for a bug in another application, as I explain below).

1. What I was doing: From the Tools > River2 > Pages menu, I selected a page to view (any one, it's the same bug no matter which page).
2. What I expected to happen: I expected the selected page to open in my default web browser, Pale Moon (a Windows-optimized build of Firefox)
3. What actually happened: Nothing. Not even an error dialog.

I immediately suspected that the problem was the communication between the OPML Editor and the Pale Moon browser. After all, there was a major bug for the longest time in Firefox's DDE implementation that required a workaround.

Bottom line: the OPML Editor's DDE implementation expects that the DDE service name is the same as the name of the executable with the filename suffix removed. So, for Excel, the service name is "excel," and for Firefox it's "firefox." But the service name is determined by the application, and the Pale Moon developers decided that its service name would be "Pale Moon," not "palemoon." A simple patch to system.verbs.builtins.webBrowser.openURL resolves the problem.

if string.lower (id) contains "palemoon" { // 2/11/11; 12:09:06 AM by DJM
	ddeName = "Pale Moon";
	return (webBrowser.callBrowser (ddeName, "WWW_OpenURL", s+",,0,0,,,,"))}

The function webBrowser.callBrowser expects ddeName to be the name of the executable, from which it attempts to remove the ".exe" suffix. Luckily, if the function is passed any string without an ".exe" suffix, it just accepts the passed string as the DDE service name.

Here's the full context:

That ",,0,0,,,," nonsense is part of the DDE message that Pale Moon expects:

Note the clipping along the bottom of the statusbar, as underscores and descenders are cut off.

But check this out. Same theme, but with XP Styles enabled (not my personal preference), and the clipping is gone.

Now, look at the noise in this shot. Where is that coming from?!

Finally, check out the left-side alignment, as "Work offline" is not aligned with the other menu items.

That last one is only present when I use the Azerty III theme, but the other bugs appear in the Default theme, as well.

Seen any others?

Update: Surprise, surprise! Went through the tedious process of disabling all add-ons then re-enabling each of them one by one, and it turns out that those statusbar display bugs were caused by Forecastfox and Foxclocks (not in combination, either one alone causes the display issues).

Turns out Fedora 8 ships with a known bug. More info here. PITA.

The bug is that the channel title switches back and forth between "NYT > NYTimes.com" and "NYT > Home Page". This alternates at least once an hour, all day long (as near as I can tell). This constant switching causes one of my feed readers (FeedDemon) to alert me of the change every time it occurs. Of course this latter point is not directly the Times's fault, but it is driving me insane.

Screenshots to prove that I'm not already insane:

If you look closely at the raw RSS feeds, you will notice that they appear to be using two different tools to generate the same feed. So I guess the two tools are not configured exactly in sync with one another.

Welcome back to 1995!