jackal

Was a change made?

I've suddenly started having this issue in Chrome (12.0; WinXP Pro). And yes, it seems to be happening on threads I've specifically read on this machine before.

Edited to add: I don't know that it's related to this issue. I just scrolled a bit further down MyFlyerTalk and am seeing new posts all the way back to June 21. I know I've been off FT for a couple of days, but I'm pretty sure June 26 was more than 48 hours ago...

Did someone screw with either the database or the reset-new-posts-after-X-days setting? June 28 is one week ago, which is what the previous setting was...and the threads I was clicking were opening back to about June 28. I'm thinking that it's a database issue. Well, think I'll go over to a friend's house for movies instead of fighting with FT tonight. See y'all tomorrow after the IB staff gets into the office and fixes things.

Silver Fox

And this morning a couple of threads appeared for me from June 21 and 25 where I was the last poster.

baliktad

Yes, from previous posts, it seems that the magic number of days to track was just this evening adjusted to approximately 15. Threads where the last post was 10-15 days ago all suddenly appeared in my My Flyertalk page as well.

josephstern

Yup. I thought I was clear of all of this by avoiding FF5, but now it seems to be happening in Chrome for me, in certain threads. Fun.

Silver Fox

It really is poor form, for a forum with as many members as there are here and as popular this is with all the search engines, that this has not been fixed yet.

IB-types: even though you think that you have nothing to report, sometimes just giving a daily update that you are working on "something" works wonders for your customers.

IB-Dick

That won't be necessary, as we think we're going to replace the links with 302's.

The problem we're having with fixing this now is that there are two separate systems that handle redirects, vB and vBSEO. vB defaults all redirects to 302, which is incorrect in most cases, but incorrect in this case, and vBSEO defaults all redirects to 301, which is correct in most cases, but incorrect in this case. We actually have a plug-in that changes vB's 302's to 301's, since we weren't aware of this specific use case. Neither of these handle redirects conditionally, it's a 301 or 302 status for everything.

The proper fix is to re-write both sets of code so that they treat this instance differently. Since that will take some time, we're trying to find an appropriate interim fix that will restore the functionality without messing up anything else.

baliktad

Simply replacing the existing 301 (permanent) redirects with 302 (temporary) redirects will not resolve the problem for existing users. The entire point of a 301 redirect is to allow the browser to avoid contacting the server if it already has a cached answer. If the browser doesn't ask the server, what the server answers doesn't matter.

Now if the 302 redirect were combined with a new name for the magic new-post page, every client would see it as a new link for which there is no cached answer, and the problem would be resolved for everyone. Short of that, everyone will be required to clear their caches.

I am glad that IB has finally acknowledged there is a problem and that they have identified a potential solution. I have zero knowledge about FT's architecture, servers, databases or infrastructure, but armed with the facts and tools built into an affected browser, it took me less than an hour to diagnose the problem conclusively. I'm disappointed in myself for not digging deeper earlier, but I'm more disappointed that IB, as the owners and stewards of this set of forums, has ignored the issue for so long, especially when it affected so many people and was so readily discoverable.

I do hope that IB can get a fix deployed soon so we can all resume conversing about topics we care about rather than technical meta-minutiae.

evanderm

the main way I navigate through Flyertalk is to look at the threads in which I have posted and then I view first unread. Since yesterday threads are showing unread posts dating back to June 21 5:55pm EST despite the fact that I know I have read the latest posts. Also clicking on read first unread often will take me to the first post on or after June 21 in the evening.

FN-GM

Not checked all 10 pages of posts so sorry if i am repeating this.

I am running FireFox 5 on Mac OSX 10.6.8 and i am getting the issue also.

Thanks

ftnoob

I thought one of the reasons for the 301s in the first place was to clear the old format links (and the many duplicate links to the same content) out of the search engines. If all redirect response codes are changed from permanent to temporary, won't some of the pre-vBSEO issues return?

Is it not feasible to use the old format (php page) links instead of the new-post.html links? This "lying" as to what the link is all about (html, suggesting static pages, versus php, suggesting pages generated on demand) is the real root of the problem, IMO. I understand the use of .html for the threads, but it seems inappropriate for the first unread URL.

Using the GreaseMonkey script posted above entirely eliminated the problem for me. My guess is browsers (or at least FF5) realize that a request for a php URL with parameters should be submitted to the server, even when the cached response is 301. When I view the traffic, I do see FF5 has actually resubmitted the showthread.php?goto=newpost&t=1234567 URIs and received a new 301 response even for an already cached URI.

(An alternative explanation is that a future release of FF will update handling of cached 301 responses for that type of URI. Anything in the specs about that, baliktad?)

I agree; I was going to say the same thing. The new name could be as simple as new-post.shtml...which perhaps might even work with a 301, as .shtml, like .php, indicates that content is generated dynamically.

I wouldn't go that far, as I certainly don't have the impression the problem was ignored.

I am however, disappointed that IB's efforts were stymied for so long simply due to only testing in a developer's environment. I would have thought that all the tech staff would have Firefox configured with multiple profiles, one for development and one for testing the user experience. Wouldn't proper internal testing of changes include testing in an environment like a typical user's environment (including old slow computers and browsers), rather than only a developer's environment?
As explained in the linked article Firefox even allows having multiple profiles open at once. Wouldn't it be good practice to read the forums with a more-typical user profile (including common FF extensions), and reserve the stripped down developer's profile for development?

baliktad

This is expected and happening correctly as specced and designed. As I posted above, the response to showthread.php includes specific no-caching headers that instruct the client not to reuse the response. The problem in question is the response to the thread-new-post.html page, which has a 301 response but lacks any explicit no-caching directives.

Three months is not an acceptable amount of time to recognize a problem. Up until a few days ago, it was IB's staunch position that the problems were the result of user configuration or browser manufacturers; basically anybody but FT.

This was a bit shocking to me as well. It is indicative of a small-time internet shop with one guy tooling around doing dev and test work on his one machine. Clearly there is no test environment, no dedicated testers, no real interest in finding and solving problems before users run into them head-on. I expected more from a forum the size of FT.

ftnoob

Oops, I hadn't noticed this thread was that old. I did previously point out to someone that the problems pre-dated FF5, but when I wrote my prior post I was only thinking about the time elapsed since the release of FF5. My bad; I retract my disagreement with your assessment. (I also didn't realize until a moment ago that you are also the OP.)

I meant to mention in my earlier post that IB did seem to exhibit some skepticism regarding the reality of the issue (as opposed to ignoring it).

Is FT even all that large a portion of Internet Brands? I have no idea about how responsibilities are shared (or not) there, but considering the size of IB overall...

ftnoob

I've not yet gone back to double-check the traffic, but when I examine the cache info as displayed by FF5, I can't detect a difference. What am I missing? (Click images for details.)
I realize there could be caching info sent with the original response that is not viewable within FF, but my quick scans of those on prior testing didn't turn up differences that I understood to be noteworthy. (But I'm a n00b at this stuff.)

baliktad

It seems like you are inferring FT's caching instructions by what you find in your browser cache afterwards. This may be helpful information about what the browser actually has in its cache (which may or not be available or used for future requests), but it doesn't definitively indicate what sort of responses FT is sending. You'll have to use a more "live" tool to examine requests and responses as they go by to get that. Unfortunately, I'm more an IE guy, so I can't recommend any tools for FF offhand, but I'm sure there are some out there.

Regardless of the browser or tool you use, the requests and responses you'll see will look very similar to the code snippets I included in post #128. The first request (for thread-new-post.html) will receive a HTTP 301 response with no further caching headers. The subsequent request for showthread.php will also recieve a HTTP 301 response, but will also have 3 additional headers that instruct the client to NOT cache the result (whether the browser actually does or not is up to the browser). These specific instructions are:

In reality, browsers today effectively cache everything and then decide later if or how to use that cached information, so what currently exists in the cache is probably not a good indicator of what will or will not be requested later. You'll just have to watch it as it happens to confirm the behavior for a given browser.

ftnoob

And that is specifically what I thought I was seeing in all cases. Obviously I could have been mistaken.

I didn't have answers for questions like "what does a value of zero mean?" Zero could mean a zero length cache life, or it could mean "no expiry date, so cache forever." The fact that both cache entries read:says to me that either the initial response header was the same, or any differences in the initial response header are irrelevant.