On Magic

We discovered an interesting IE6 feature when we pushed out caching changes earlier this week for Journals.  For posterity, here are the technical details.  Our R8 code started using "conditional GET" caching, meaning that we supported both If-Modified-Since: and If-None-Match: HTTP headers.  The way this works is that, if a client has a version of a page in its cache, it can send one or both of these headers to our servers.  Like this:

If-Modified-Since: Tue, 26 Sep 2006 21:47:18 GMT
If-None-Match: "1159307238000-ow:c=2303"

If-None-Match, which passes an "entity tag" or ETag, is better to use and was designed to replace the If-Modified-Since header.   (If-Modified-Since has granularity only down to a second, and can't  be used to indicate non-time-based changes.)  In our case we actually have two versions of our pages which can be served up, one for viewers and another one for owners.  We really only want to cache the viewers' page.

When our server sees a request like the one above, it first does a quick check (in this case it'll ignore the If-Modified-Since and use the ETag) to see if the client already has the latest version; if it does, it returns a 304 Not Modified result.  The big win is that this can be done very very quickly and efficiently, while building a 200KB web page takes lots of work.  If the client doesn't have the right version, though, the server returns a 200 and sends new headers, like these:

Last-Modified: Tue, 26 Sep 2006 21:47:18 GMT
Etag: "1159307238000-c=2303"

If you're obsessive with details you might notice that the modification date is the same as before, but the ETag has changed (the -ow:c has changed to a -c).  When the second request was made, it sent cookies that told the server that the user was the owner of the blog.  So the page is different and therefore the ETag is different, but the last date modified is the same.  We're expecting browsers and caches to detect the change and refresh the page.

This all works fine... except for IE6 (and the AOL client, which uses IE6 under the hood).  IE6 seems to see the Last-Modified: timestamp above and simply stop, ignoring the Etag: header and the fact that we're returning a 200 response with new content.  I've sat and watched the data flow in and out of my Internet connection and verified that IE just drops the 60K or so of content on the floor, as well as the new ETag, and re-uses its old version.  The only way to prevent it is to force a reload using ctrl-Reload, or clearing your Temporary Internet Files.

What this means is that if you change "who you are" by logging in or out, and nothing else changes, you will get a stale, cached version of your own blog's page.  Which is certainly not good.

As of this morning, we're running with caching turned off on journals.aol.com but with a bug fix on beta.journals.aol.com.  The bug fix is simple:  Don't send Last-Modified: headers.  So we only send back the Etag:

Etag: "1159307238000-c=2303"

Which forces IE6 to pay attention to it, fixing the problem with IE6.  IE7, by the way, works either way; go Microsoft!

This all means that we're not going to try to enable caching for non-Etag-aware clients and caches.  Since non-Etag-aware seems to pretty much equate to old or buggy, and not having caching is just a minor performance hit, this seems to be a pretty reasonable approach in theory.  The question now is, will practice accord with theory?  We really need people to hammer on http://beta.journals.aol.com/yourscreenname over the next few days and give us feedback.  See Stephanie's post: Like Magic, We're Back Where We Began... and please leave us feedback!

Another use for feed licenses: Splogicide

Doc Searls just changed his blog license to Attribution-NonCommercial-ShareAlike 2.5... in order to clearly deny splogs reblogging rights to his content.  Interesting, though I think there may be some unintended fallout.  But there are some cool applications for this.  What if someone built a tool to make it easy to find such copy right violators (academics use these tools to find plagarism)? With an accompanying service to aggregate complaints and, when they reach a sufficiently remunerative level, send attack lawyers after sploggers.

Update: The collective intelligence of the blogosphere is a mighty thing.  In a comment below, Doc points at an open source plagarism detector from UCSB (my alma mater) that already does Internet searches.  Hmmm.... 

AOL's Open Source Contributions to Dojo

It's nice to see something your team has worked on being put to good use.  In addition to other things, we open sourced the JavaScript Compiler tool my group has used internally for several years.  (It's actually more of a linker and compressor than a compiler since of course the output is still JavaScript.)  We're also contributing new code to Dojo, including a pretty cool cross domain XML request mechanism.

Sam Ruby presents "Teenage Mutant CyberSurfers"

This afternoon, Sam Ruby was nice enough to reprise a version of his recent talk at AOL Silicon Valley.  There's a real independent convergence between Sam's observations and predictions and the fictional world described in Vernor Vinge's Rainbows End.  Which as I understand Sam is just now reading :).

Update:  The audio is up on our podcast feed already!

AOL Pictures Beta and woohoo

In conjunction with the new Pictures Beta, there's a cool tool called woohoo which displays a an AIMPages picture gallery in a widget, embeddable anywhere.  Fun stuff...  for example:

Feeds Best Practices

The slides from my RSS/Atom Feeds Best Practices talk from lunch today are up now.  There was a good discussion afterwards and hopefully we'll put up a podcast. I'm more convinced than ever that the key to a successful presentation is: free food.

URL format change for Journals

One of the recent changes this week in Journals is an update to the format of our entry URLs.  We're essentially adding the entry date and title to the URL, for example:

.../entries/2006/07/13/rest-and-the-authorization-header/1354

So anyone who may be parsing our URLs -- be aware that the format has changed :).  We will, however, do a permanent redirect from the old URLs to the new ones.