Lesson one:
10.3.2 301 Moved Permanently The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the Request-URI to one or more of the new references returned by the server, where possible. This response is cacheable unless indicated otherwise. (RFC2616: Hypertext Transfer Protocol -- HTTP/1.1.)
It's pretty obvious, you'd think. If a webserver sends a "Moved Permanently" response, an HTTP client ought to rename bookmarks to point to the new address, since the old one is no longer valid and will never be valid again. RSS readers tend to follow this rule religiously. Mark Pilgrim's feed parser documentation states:
If you are polling a feed on a regular basis, it is very important to check the status code (d.status) every time you download. If the feed has been permanently redirected, you should update your database or configuration file with the new address (d.url). Repeatedly requesting the original address of a feed that has been permanently redirected is very rude, and may get you banned from the server. (HTTP Redirects [Universal Feed Parser])
(Most of the time it's a good rule. Javablogs follows it.)
On a recent trip to the USA, Scott stayed in a hotel with a 'net connection. The connection was one of those with an arbitrary web-based registration that made sure you'd agreed to their ass-covering terms of service. Until you had agreed, the hotel's proxy would redirect any HTTP connection to the registration page... using the 301 status code.
Within a few seconds of plugging in the ethernet cable, all of Scott's RSS subscriptions had been silently replaced with the hotel's registration page URL. All the original feed URLs were lost.
Lesson Two:
The Servlet 2.3 specification defines HttpSessionListener#sessionDestroyed thus:
Notification that a session was invalidated.
If you follow the specification to the letter, as many servlet container implementors did, you end up with a totally useless method. Sure, it gets called when a user's session is destroyed or times out. But since it's only called after the session is invalidated, you can't do anything with it.
Want to know what was in the session? Can't, it's invalid. Want to do some cleanup on objects in the session before it is dumped? Can't, it's invalid. Want to know who the session belonged to? Can't, it's invalid.
Thankfully, for the 2.4 spec the wording was fixed to read:
Notification that a session is about to be invalidated
