I only bought it last year, and already my Netgear WGR614v2 router is crapping out. It worked OK in Cambridge, but the new faster net connection seems to be giving it trouble, and if I open too many HTTP connections–say, to check a whole bunch of RSS feeds, or use BitTorrent–it crashes. This sucks. About the last thing I want to do is spend more money right now, but it’s really looking like I need a better router.

Bringing clarity

As part of my mission to bring clarity to the world, let me explain the so-called “302 exploit” you may have heard scare stories about. Background HTTP, the protocol used to serve web pages, has two numeric codes that can be returned by the web server to direct the client (browser) to a new URL: 301 and 302. A 301 redirection means “The page you requested has moved permanently. Please go to the new address I am providing you with, and update your bookmarks.

Tinfoil hat alert

According to Google Watch, our favorite search engine is dying. Supposedly Google is not indexing anywhere from ten percent to seventy percent of the pages it knows about. Well, those are some pretty huge error bars, which right away scream out “wild speculation”. But if we read on, the guy offers as evidence the fact that his web site,, appears as a bare URL in the Google index, rather than having the conventional snippet of content and careful indexing.

Not a good week for timwi

There’s another major bug in one of the IE ActiveX controls installed as part of Windows. It allows any web site to run arbitrary code on your system via malformed HTTP requests. Microsoft have issued a fix for this one. The problem is, the original broken ActiveX control is still out there, and is signed as trusted code with a Microsoft signature which doesn’t expire. So nefarious web sites can simply request the old, broken version be downloaded and executed in preference to the new one, then use the old security hole to reformat your hard drive.

J2EE battles

After about three days of more-or-less solid effort, I have almost got a WebSphere development environment running. WebSphere is running, the HTTP server is running, SSL is working, and DB2 is running… however, the HTTP server doesn’t map the /servlet/ URLs to WebSphere when I connect to it via SSL. I’m assuming the problem is somewhere in the httpd.conf file, which is huge and ugly. I’ll have to sit down with the documentation tomorrow morning and hope for an “Aha!