The comments about clearing the cache resolving the issue got me thinking, so I did a little data-gathering.

The process by which a browser navigates to the last unread post has been explained above, but I wanted a closer look at the traffic to see if something funny was occurring. The fact that the newest browsers are affected would seem to indicate that as the browsers are becoming more and more standards-compliant, incorrect or outdated behaviors are being exposed.

First, a little background. When a browser requests a web page, the server can respond all sorts of different ways. If the page doesn't exist, many people are familiar with the "404 Page Not Found" error code. If it exists and everything is fine, the server responds with "200 OK" and the contents of the page. There are actually many such codes which are grouped into series: 200-series indicate success, 500-series indicate server error, etc.

The 300-series response codes are interesting, and as a group, categorized as the redirect responses. This generally means the client (browser) has made a request, the server understands it, but the server wants the client to look elsewhere for the content. FT employs a 300-series request when redirecting the browser from the new-post "magic" link to the actual post. Let's take a look at the raw request and response for a problematic thread:

Starting from my My FlyerTalk page, I click on the First Unread Post icon next to a thread title I'm interested in. In this case, it's the AS Newbie thread, which I generally track whenever I'm online. Here's the request headers my browser sends. Note that this is the new-post "magic" link:

Now here's what flyertalk.com sends back: a pointer to a showthread page identifying a specific post ID. This response basically boils down to "I understand what you want, but it's not here. Please ask for it at this new address."

The client immediately makes a new request for this showthread page. Here's the browser asking flyertalk for the new page it was told to look at (some cookie values redacted for privacy and brevity):

Showthread.php basically takes a post ID and generates a search-engine friendly URL. The server responds with yet another redirect:

The client accepts this new address and makes a 3rd and final request for the page it wants:

Finally, the server responds with the actual page content the user cares about. Only the headers are presented here, but the content is delivered immediately following:

Now some analysis. The reason the 300-series codes are so interesting here is that the different codes have different meanings. Lots of info on Wikipedia, but the one FT uses is 301 Moved Permanently. As the description indicates, 301 Moved Permanently is useful when a page used to be located in one place, but has a new permanent home somewhere else. It's an easy way to tell a client "look somewhere else," but in this case, it's wrong, because this response code really means "look somewhere else, and don't come ask me again, because the answer will always be the same." As defined in the RFC: "This response is cacheable unless indicated otherwise."

All this means that when a user clicks on a new-post "magic" link, FT is responding with a URL to specific post, and specifically indicating to the browser that it CAN and SHOULD save that answer for later. So later, when that thread comes up again in your My FlyerTalk, modern browsers will default to their cached values instead of taking the time to round-trip to the server. This is good design as it allows the browser to save one entire unnecessary round-trip, which can speed up the browsing experience significantly.

So what's the fix? Well, FT has already figured it out. Examining closely the responses above, you can see the other 2 responses from FT (including one other 301 response) both include specific directives to the client to not cache the results. These are the 3 relevant lines:

I would expect that if FT added these no-caching directives to the new-post magic redirector, the issue would be resolved. Alternatively, the new-post magic redirector could be adjusted to use a more appropriate redirect response that does not suggest the client cache the results. 307 Temporary Redirect is probably the suitable option here.

Edit: Here's the post that explains this behavior is new in IE9 that basically confirms my analysis above. The problem is definitely with FT's implementation of 301 response code, and is only just now being exposed by new efficient browsers.