I've read ~120 papers and a couple of programming books over the last few months, and I'm starting to see AspectJ when I close my eyes. Rather than press on (which is what a _real_ programmer would do), I've ditched programming books this month and started on some other stuff: Against The Gods, a look at the history of probability and risk management, The Innovator's Dilemma, a discussion of disruptive technology and its impact on companies, and Mathematical Logic.

I'm also taking a second look at Software Ecosystem, which I didn't take in completely on my first pass.

I'm a couple of months behind the pace, but I finally got a look at the Amazon / Avalon PDC demo today. It is pretty cool.

UK bank Egg have also put together a demo on the same platform that is really interesting. Avalon looks like the future. I can't wait to implement something on this!

When an ASP page experiences an error, a HTTP 5xx message is often returned to the client, indicating some server error. Anyone who has coded some ASP (badly) will know the drill on this. While working on some web page caching problems, I got to thinking about the effect of Response.Buffer = true and Response.Flush calls that precede a server error - in this circumstance, the client is going to get a response header (a 200, say), and then... kaboom. They will probably get a load of strack trace or whatever else the web server is configured to give them in the event of an error. But no 500.

The funny thing about this is that on my IIS6, the logs say 500 in this situation, not 200. So in some circumstances I could send my client a 200 + a load of junk, but log it as a 500 on the server side. This presents some challenges for my spelunking of cache problems - did the client really get a 500, or some other code? This is important to me, because HTTP 1.1 makes some interesting statements regarding caching and 5xxs:

"If a cache receives a 5xx response while attempting to revalidate an entry, it may either forward this response to the requesting client, or act as if the server failed to respond. In the latter case, it MAY return previously received response unless the cached entry includes the “must-revalidate” Cache- Control directive." (Section 13.8, RFC 2068)

This doesn't get me any closer to solving my caching problem, but it has been fun getting into the nitty gritty of HTTP.