About FEMA

I saw this on the Daily Show and got a good laugh out of it, so I wanted to make sure that this little gem of a graphic was preserved for future reference before FEMA wakes up and removes it from their website.

Notice how FEMA’s six stage process for dealing with disaster actually leads to… disaster!

The graphic is still on the FEMA site right now.

IBM Mainframe Pricing Models

The pricing model for owning and operating an IBM mainframe is quite stunning. It’s probably the most lopsided pricing scheme that anybody has ever managed to sell… ever.

Buyer: “Hi, I need a Ford Escort. Please sell me one”

Seller : “Sure, I hear your need. Since you’re an On Demand business that must respond quickly to customer needs, here’s what we’ll do. We’ll sell you a Hummer. You buy the Hummer from us at three times the normal market price. Since you only need a Ford Escort right now, just avoid using the rear 2/3 of this vehicle, only drive it in second gear and never go over 30 miles per hour. You pay for gas, maintenance, repairs and other modifications. And if you ever need the extra capacity that this bad boy offers, you can just call us up and we’ll figure out how to charge you for that as well. Sound good?”

Buyer: “Well… sounds a bit…” medrol pak

Seller : “Oh, and you have to pay us for every mile you drive in it.”

Buyer: “I’m sold!”

NY Times sends incorrect mime-type header for their OPML feed

The NY Times provides an OPML feed that lists their RSS feeds, but they are currently sending the wrong Content-Type with the HTTP response:

Content-Type: text/plain

According to the OPML spec (and, believe me, I’m using the term “spec” loosely), the correct Content-Type should be text/xml, text/x-opml or text/html depending on what the client says it can support.

Does this matter? Well, do web standards matter (only answer this question if you are willing to consider OPML a standard)? More importantly, this is just another indication that I’m spending too much time looking at HTTP headers.

Yahoo Tries to Kill del.icio.us

I bumped into Yahoo’s new My Web 2.0 service today. It’s basically their del.icio.us-like social tagging and bookmarking service. Their new UI looks… well, alright, but it’s clear that they’re miles ahead of del.icio.us in terms of bringing this idea into the mainstream.

One feature of the Yahoo service is that it allows you to import your bookmarks from del.icio.us. I tried it and it seems to work just fine. It’s not, after all, that hard to do now that we don’t have to screenscrape anymore! mentax

Import del.icio.us bookmarks to Yahoo

Of course, you’re only going to think that this is a feature if you’re not the people who run del.icio.us….

Flickr Sends Goofy HTTP Headers

Flickr is sending the following HTTP headers when I request an image from their site:

http://static.flickr.com/25/45701618_b33d84770b_s.jpg

GET /25/45701618_b33d84770b_s.jpg HTTP/1.1
Host: static.flickr.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5

Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: cookie_epass=9df5184c71b811e5bf1081de83e24d51; cookie_accid=16665; cookie_session=16665%3A9df5184c71b811e5bf1081de83e24d51; use_master_until=1127567132
Pragma: no-cache
Cache-Control: no-cache

HTTP/1.x 200 OK
Date: Fri, 23 Sep 2005 01:13:26 GMT
Server: Apache/2.0.52 (Red Hat)
Last-Modified: Fri, 23 Sep 2005 01:13:23 GMT
Etag: “91e011-d08-1dacd2c0”

Accept-Ranges: bytes
Content-Length: 3336
Content-Type: image/jpeg
X-Cache: HIT from storage7.flickr.mud.yahoo.com
Connection: close

This is completely valid HTTP, but I really wish they were sending back a proper Expires header like this:

Expires: Mon, 24 Oct 2005 15:12:45 GMT

If they sent back this HTTP header, my browser wouldn’t have to perform conditional-GET requests for subsequent loads of images on Flickr. The part of the HTTP request that makes the GET conditional is highlighted below:

GET /25/45701618_b33d84770b_s.jpg HTTP/1.1
Host: static.flickr.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: cookie_epass=9df5184c71b811e5bf1081de83e24d51; cookie_accid=16665; cookie_session=16665%3A9df5184c71b811e5bf1081de83e24d51; use_master_until=1127567132
If-Modified-Since: Fri, 23 Sep 2005 01:13:23 GMT
If-None-Match: "91e011-d08-1dacd2c0"
Cache-Control: max-age=0

HTTP/1.x 304 Not Modified
Date: Sat, 24 Sep 2005 15:19:32 GMT
Server: Apache/2.0.52 (Red Hat)
Etag: “91e011-d08-1dacd2c0”
X-Cache: MISS from storage7.flickr.mud.yahoo.com
Connection: close

Instead, my browser would notice that it has been told not to request this resource until Oct 24th, which is exactly one month from today and would display th e image from the local browser cache. There wouldn’t be any network overhead at all and Flickr images would be served a lot faster.

I don’t see what the point of only allowing conditional GET requests is. Flickr isn’t benefitting anybody by doing this. Failing to use Expires: headers for static content only serves to slow down the user experience and increase load on their systems.

Sysadmins at Flickr: read the mod_expires documentation and switch this thing on.