FlyerTalk Forums - View Single Post - Flyertalk can't seem to remember last viewed post
Old Jun 28, 2011 | 4:14 pm
  #73  
ftnoob
Moderator, Southwest Airlines and Choice Privileges
All eyes on you!
15 Years on Site
 
Join Date: Mar 2008
Location: Central Texas
Posts: 3,112
Originally Posted by sc flier
that maybe some users here might get some ideas about how to address it on the browser side?
Nothing can be done to fix the problem on the browser side, although there is one thing (see below) that can be done to slightly reduce the hassle it causes.

Originally Posted by sc flier
Could someone provide a technical explanation about how the system is supposed to keep track of the last viewed posts...
Most of what you wrote in your later post sounds like you have a decent grasp on it, but I'll spell out some details just in case as well as for others still learning about the issue.

(The original formatting from above perhaps made it difficult for non-techs to follow, so let me add some background and attempt some reformatting.)

Understand that on the thread listing pages, the URL attached to the Go to first new post icon () is what for non-technical consumption I refer to as a "magic url." I call it that because there is no actual page at the location flyertalk.com/..../....-new-post.html, and for someone who doesn't understand what happens behinds the scenes, it feels like magic: the exact same URL can display different content to everyone with a different last read post for the thread.

When you attempt to retrieve a -new-post.html URL, the server uses data stored in your cookies to figure out who you are, then looks in the database for your "last read post" value for the thread in question. It also has to look up your posts-per-page setting (from the database or another cookie) to calculate on which page your first unread post should appear. When the server has all the variables it needs from the database (and/or cookies), it builds the redirect URL, and tells the browser to display the redirected location instead of the URL it requested.

One way you can confirm that this is going on is to change the Firefox network.http.redirection-limit value on your about:config page. The default value is 20:

If you set the value to zero and attempt to retrieve one of the "magic" -new-post.html URLs, the redirect process will be shut down by Firefox and you will see this (somewhat misleading) message:
If you try it, be sure to set the value back to 20 after your experiment.


Now here are the reformatted examples from an earlier post:

Code:
[1] http://www.flyertalk.com/forum/rr/1229903-southwest-early-bird-boarding-sham-new-post.html
[2] http://www.flyertalk.com/forum/rr/1229903-southwest-early-bird-boarding-sham.html#post16620273
[3] http://www.flyertalk.com/forum/rr/1229903-southwest-early-bird-boarding-sham.html#post16623396
[1] Original virtual URL
[2] Incorrect redirect experienced on FF 5
[3] Correct redirect experienced on FF 4
For those who aren't already aware, the #post... part of the URL instructs the browser to scroll to a particular "anchor" in the page, rather than just go to the top of the page.

This is important to note:
Originally Posted by ftnoob
On the computer where new-post redirected to the wrong URL, the View First Unread link was nevertheless correct.
Conclusion #1: The server has the correct information in the database!

It is also important to note, however, that if you are not currently viewing the page with your first unread post, the View First Unread link is not a real URL, it is simply the -new-post.html "magic" URL.

Conclusion #2: We can slightly reduce the hassle of this bug by setting our posts-per-page to the max (40, IIRC). Then if instead of clicking the first unread link from the thread list page, we:
  • first click a link that takes us to our correct first unread page;
  • then click the View First Unread link on that page;
we will end up at the right post. By setting the posts-per-page to 40 we reduce the number of mult-page threads as well as the number of times we end up on a page that is before or ofter the one that actually contains our first unread post. It does take two clicks instead of one, but it is far better than trying to find the first unread post be scanning the page, or adding yet another click to get to the right page after the first click failed. (If you want to occasionally try the "magic" URL to see if the problem has been fixed, you can always use ctrl-home to jump back to the top of the page to access the View First Unread link. (I don't like setting posts-per-page as high as 40, but it is the lesser of two evils while this problem exists.)

There is one point where you went astray, including an unreliable thread link toward the end (I removed the hot link so it can be easily read):

Originally Posted by sc flier
Today, I keep getting reminded of last night's post pointing out that Caroline is not much of a coke head every time I check the new posts in this thread...
http://www.flyertalk.com/forum/omni/679219-wimbledon-tennis-grand-slam-tournament-39.html#post16636288
First off, no link like that would ever appear attached to the Go to first new post icon () on a listing of threads. On the forum page, only the Go to last post icon () links to that type of URL. You gave us the URL that the server is redirecting you to when you click the "magic" url. The link when you view the forum containing that thread should look like:
http://www.flyertalk.com/forum/omni/679219-wimbledon-tennis-grand-slam-tournament-new-post.html
On a tangent, it is important to know that the -39 part of the URL normally causes the link to fail for anyone whose posts-per-page setting causes Post 16636288 to appear on some other page. Don't attempt to share post-specific links using -pg.html style links on FT. In FT posts and PMs, wrap post tags around some text to link to a specific post:
[ post=16636288]Caroline is not much of a coke head[/post]
Caroline is not much of a coke head
(Remove the extra space from the markup on the first line to create the hotlink in the second line. The link is dynamically generated from the markup every time the page is viewed, based on each person's posts-per-page setting.)

Originally Posted by sc flier
Is the server caching the time for the redirects? So when I return, I'm redirected to the cached value? But then sometimes, the server's cache gets cleared?
Impossible to say from our side, but we do know that the correct information is getting into the database in at least one place. It seems clear to me the problem has to be in the part of the code that builds the redirect URL for us. Whether due to caching or the data otherwise being stored in multiple places and not updated in all of them, we'll have to leave it to IB to figure out.
ftnoob is offline