I wouldn't assume that at all. FF is responsible for its own cache management, and the response headers received from a server are only one influencing factor. Further, the fact that an item is in the cache with no expiration doesn't necessarily mean the item will or won't be used on the next request. It simply mean the item exists in the cache.

Watch the request over the wire. You'll see that the first request for thread-new-post.html gets a HTTP 301 with no further caching directives, which is the real problem here.

Just popping in here to let you all know that we're still working on a solution for this very frustrating issue. Thank you for your continued feedback and conversation.

Thanks for the update IBKim, it's great to see some proactive progress notes from IB. Do you have any further information about either the scope of the solution or the timeline we can expect for resolution? Is this something we might expect within a week? A month? A year?

Unfortunately, no, I don't have any further information or details. I know Dick and Paul have been very active in communicating with you lately but they're hard at work on the problem today and haven't had the chance to reply. So I really wanted to make sure you all knew we were still working on the problem and that we haven't forgotten you. :)

Thank you!

You are correct. I had a chance to test again in less of a rush. Here is all the header info:Contrast that with the response for the calculated redirect URL:
Or is it? Here are the headers for a request for the old style .php?goto=newpost&t=1234567 URI:So neither the new-post.html magic URL nor the old-style goto=newpost URI receive the additional cache directives, yet when the .html URI is cached, the browser bypasses the roundtrip to the server and back, while the .php URI is submitted even if cached.

BTW, I found no discrepancies between the live communications and what FF5 stored in its cache.

I haven't followed all the technical details, but just as another data point, based on the conversation above I turned off caching and don't seem to have this issue anymore. I'm running FF5 on Win7 and first started having the issue a few weeks ago. At one point I tried using IE9 which started out okay but eventually also showed the same problem.

Happy Monday, everyone. We're still on the case! Hopefully we'll be able to give you more information tomorrow. Keep that feedback coming.

- Kim

Firefox just came out with version 5.0.1 for my Apple Macintosh computer, so I am trying it out.

In the meantime, FlyerTalk has been working with no problems in Safari.

This seems to be working for me, as a temporary measure.

It appears that after the scheduled maintenance this evening, the -new-post.html page now returns a HTTP 302 redirect. I believe this will resolve the issue. Anyone previously affected should completely clear their cache/cookies/history to nuke any old URL references previously stored by the browser.

I will be watching closely in the next few days to determine whether the fix resolves the issue completely. I will be glad to finally be rid of this vexing issue.

We changed it to a 302 earlier in the day. This maintenance was to fix some things that that change broke.

Also, you shouldn't need to flush your cache. I changed the link so it's now linking to '-new-post1.html'. I'll change it back in a week so that any saved bookmarks won't be broken.

As of right now, it seems to be working for me. :)

So far so good...fingers crossed....

Seems to be working now. Thanks!