crazed monkey

Feedster:

If you’d like to use an image you find with Feedster Images, you should remember that it is considered bad blogging form to embed images from other sites in your own blog, thus using their bandwidth for your blog. Check with the author of the blog to see if its [sic] ok and then copy the image to your server if that’s ok.

I wholeheartedly agree. However, Feedster does not seem to follow its own advice, particularly on its page of images included in current weblog posts. (I found this out after I started to receive hits for the image contained in my Becel Ride for Heart post.) The obvious and easy thing to do would be to cache resized copies of the images being displayed. Instead, your browser is forced to download the original image from each weblog, which is then resized to fit the thumbnails. As a result of this disgusting display of hypocrisy, I am blocking all images which have Feedster as their referrer.

Posted on May 27th, 2003 in computers, internet - No Comments »

The day for the 2003 Becel Ride for Heart draws near, and I just thought that I’d take this opportunity to request that you sponsor me for the ride if you haven’t already done so. I liken donating to the Heart and Stroke Foundation as a kind of insurance. Your money goes towards research which could save either your life or the life of someone you care about. This coming Thursday is your last chance to sponsor me online, so please do not hesitate! As I mentioned in a previous post, there are added incentives for webloggers and website owners.

Taking a cue from Frank Yang, who will be joining me on the ride, may I present the Trek 4300 which I will be riding on June 1st. I bought the bike around a month ago and have since logged more than 300km on its wheels, most of which was in a series of 50km rides down the Don Valley Trail. Sadly, the weather this month has not been all that cooperative and so I have not been able to get as much practice as I had hoped. Speaking of which, the weather for June 1st looks to be a 90% chance of rain, which will no doubt take most of the fun out of the ride. Luckily the ride is for charity so at least someone will benefit, even if it isn’t my soggy ass.

Posted on May 27th, 2003 in meta, person - No Comments »

One of my biggest beefs with working with HTML and CSS was that the separation of content and style had not gone far enough. One still had to consider the structure of the document in terms of element ordering. For instance, when writing a white-paper one would have to decide whether to place the table of contents before the summary within the HTML and not within the associated CSS. To change the ordering after the fact, one would have to change the content, not the associated style.

This styling issue is fixed somewhat with CSS3 and the introduction of the move-to property within the Generated and Replaced Content Module (via Sjoerd Visscher’s weblog). This is what I envisioned as a solution to the above problem except that one cannot move elements to anywhere in the document. One is instead restricted to moving elements to later within the document. I’d like to know why this restriction exists. I suppose the ability to move elements to anywhere within a document would degrade rendering performance, but surely that is an implementation detail. A browser could either choose to render the image and move elements on the fly or wait until all content is received before moving elements around. Still, it’s a step in the right direction towards the nirvana of complete separation of content and style.

Posted on May 20th, 2003 in computers, internet - 1 Comment »

After a long haitus, Ed is back with another selection of rare groove tunes:

1. Space Lady – Lonnie Liston Smith
2. The Master Rocker – Bernard Wright
3. Double Dutch Bus – Franke Smith
4. Fat Mama – Herbie Hancock
5. Sing Sing – Gaz
6. The Breakdown – Rufus Thomas
7. Different Strokes – Syl Johnson
8. North, East, South, West – Kool & The Gang
9. Rapture – Blondie
10. Higher Ground – Johnny Hammond

And as an extra treat, here’s his current top five tracks:

1. The Bottle (Groovefinder remix) – (Bootleg)
2. Make a Change (Dub the Tech mix) – Miguel Migs Dub Plate Sessions 2
3. Spirit (in dub) Jay-J remix – Brent Laurence – Black Vinyl
4. DUBRAZIL – “Her Name Was Rio” Cosmic City’s 5am Dub – Jordan Fields
5. Out of Sight – Flash Atkins – Bosh Recordings

Eddie C is a friend of mine from university who now DJs in Banff.

Posted on May 15th, 2003 in culture, music - No Comments »

As the Tomcat user mailing list has not been much help in solving two annoying Tomcat issues, I hereby invoke the Lazy Web!

The first issue involves Tomcat blocking on a call to HttpServletRequest.getSession(). This seems to only occur when I am debugging Tomcat remotely from within IDEA under Windows XP. I am using the latest version of Tomcat, JVM 1.4.1-b21 and IDEA 3.0.1. This is possibly an IDEA issue. Since the problem only seems to occur when debugging, it is not one needing an urgent solution.

The second and more annoying issue involves a mangled Content-Length header in the occasional HTTP response. When I say “mangled”, I mean that the header field does not read as “Content-Length”, but something almost like “Content-Length”. Naturally, a response without a Content-Length field violates the HTTP specifications. The content and all other header fields are never mangled—only Content-Length, only sometimes, and usually when the length of the body is non-zero.

The following code snippet illustrates how I am setting the response:

private void writeHttpContent( HttpServletResponse response, byte[] contentsOutBytes ) throws Exception
{
    response.setContentType( "application/octet-stream" );
    response.setContentLength( contentsOutBytes.length );

    // Only bother writing if there is something to write.
    if( contentsOutBytes.length > 0 )
    {
        // Grab an output stream from the HTTP response and write to it
        BufferedOutputStream out = new BufferedOutputStream( response.getOutputStream() );
        out.write( contentsOutBytes );
        response.getOutputStream().flush();
    }
}

I have tried a few variations on the above including calling flush() on the BufferedOutputStream, and closing either response.getOutputStream() or BufferedOutputStream, but with the same result. Using response.setHeader( "Content-Length", Integer.toString( contentsOutBytes.length ) ) makes no difference, as one would hope. I also eliminated the call to response.setContentLength() but that always resulted in a missing Content-Length.

Here is an example of a mangled response:

Content-Type: application/octet-stream
Content-Lengtd><b
Date: Tue, 25 Feb 2003 17:28:49 GMT
Server: Apache Coyote/1.0

To date, I have only seen this happen on our Debian Linux box running Tomcat 4.1.16-1 from testing and Sun’s J2SDK1.4.1_01-b01. This led me to believe that it could be a problem with Debian, but a post to the debian-java mailing list turned up nothing.

Naturally, the above problem cannot be reproduced but it does happen often enough to be terribly annoying for our client devices. Furthermore, I have a few Java apps hitting the servlet on a consistent basis using HTTP/1.0 and they never experience this problem. I can’t understand how this could be limited to HTTP/1.1.

If you have any suggestions—any suggestions at all—then do not hesitate to leave a comment. At this point, I’d accept chicken bone voodoo magic as a possible solution.

Update (05/15): After spending most of today and some of yesterday investigating this issue, we have determined that it was the router causing the munged bytes, always in the same offset within a packet. The router in question is a LinkSys, and will be subsequently hurled, beaten and torched sometime in the very near future.

Posted on May 14th, 2003 in computers, java, programming - No Comments »