Originally Posted by
baliktad
The comments about clearing the cache resolving the issue got me thinking, so I did a little data-gathering.
Hey, me too!
I did some looking and discovered things like:
Still, at first blush one is inclined to say "it isn't a cache problem, because the newly served page includes information that is not in the cache!" As I was beginning to suspect, that is an outdated view; browsers have evolved. Clearly you agree:
Originally Posted by
baliktad
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.
I agree with your analysis except to point out that your explanation implies a communication from the browser to FT (and back) that with modern browsers
will not actually occur if there is a cached 301 response. This at last is the answer to something that had me scratching my head these past few days:
Originally Posted by
ftnoob
Viewing the details of the traffic we can see things like:
Code:
11:19:41.640 Status: pending GET http://www.flyertalk.com/forum/southwest-rapid-rewards/1230034-chase-rapid-reward-points-did-anyone-not-get-theirs-transferred-new-post.html
11:19:41.696 Status: 301[Moved Permanently] GET http://www.flyertalk.com/forum/showthread.php?p=16635962#post16635962
11:19:42.890 Status: 200[OK] GET http://www.flyertalk.com/forum/southwest-rapid-rewards/1230034-chase-rapid-reward-points-did-anyone-not-get-theirs-transferred.html#post16635962
Not being a web technologies expert, I found the "pending" status for the initial request puzzling. Now it is becoming clear: the status is pending because the browser intercepted the request, saying "Wait a sec, I
already know the new permanent home for that URI; I won't bother the server to ask for it, I'll just substitute in a request for the new permanent home of the URI the user clicked!" (This is the avoided round trip mentioned in your post.)
Originally Posted by
baliktad
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.
I might be behind the curve on this one, but I didn't see any clearly erroneous caching instructions sent from the server.
Originally Posted by
baliktad
I would expect that if FT added these no-caching directives to the new-post magic redirector, the issue would be resolved.
Can you double check this and confirm this specific change is needed?
Originally Posted by
baliktad
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.
I have seen both 302 and 307 mentioned, but this is exactly the direction I was going. The
-new-post.html (which as previously noted should not normally be seen by a bot) should receive a "temporary redirect" response, then the old-style .php URI should receive the 301 "permanent redirect" response. To my untrained eye, that should take care of the problem. Perhaps even take care of it in an
elegant fashion.
Originally Posted by
baliktad
Edit:
Here's the post that explains this behavior is new in IE9 that basically confirms my analysis above.
Thanks for that link; I'd been looking for discussions of updates to modern browser handling of 301 caching, and hadn't come up with much. I kind-of think I'd seen that msdn blog post, but I need to review it to be sure of what it is saying.
Originally Posted by
IB-Dick
I have caching disabled...
After reading the nearly-simultaneous posts by
Global_Hi_Flyer and
sc flier, I would have laid big money that such was the case!
ETA: left unexplained by these analyses are the upthread reports of this problem occuring in FF 4.x. I'm inclined to think those are erroneous reports, but I could be mistaken.