I ran into an unusual problem the other day. I think it may require some support from mojoportal to fix it.
Here's the trouble...I had a menu entry on my mojoportal site whose URL was redirected to another site. As it happens, I didn't do it through mojoPortal but rather through IIS6. However, I might have easily done it with the redirect manager within mojoportal.
What happens is that when the redirect is removed, neither IE9 nor FireFox (5+) learn of the change. They both keep going to the old redirected page. Huh?
What is happening is that both of these browsers introduced caching of redirects in order to enhance performance. When either of them sees a 301 redirect, they cache it and never consult the original server again to see if it is no longer redirecting. While technically that's in the spirit of a "permanent" redirect, it fails to take into account any margin for error. That is, once the redirect is cached, there is no way for the original server to undo the change.
Let's say you tried to tell the browser to go back to the original url. You could do this by setting a redirect on the target of the original redirect to point back to the original url. Guess what, now all you get is a redirect loop! You can't invalidate the original cached redirect this way. If IE9 and FF were a little more intelligent, then they might take this as a sign that perhaps it should check on the status of the original redirect and see if the server still has it in force, but neither have such intelligence.
Attempting to use such a redirect to "fix" the problem also gets cached, therefore completely breaking both URLs permanently! (for that browser at least)
Ok, so there's no fix from the server side for one of these cached 301s. Perhaps you're thinking, "You shouldn't have used a 301 in the first place if you expected it would change later."
Well, that's a very good point. It's correct that, if there's any chance the redirect could be removed in the future, then it's a temporary redirect, isn't it? It so happens that I did expect this redirect to be temporary, so that's my mistake. I should have used a 302 in this case. That way, when the redirect went away, they wouldn't have been cached by the browser.
There's a couple problems with that.
First, I made the redirect before IE9 came out, when 301s weren't cached. So it would be reasonable but not technically accurate to use a 301.
Second, I would have made the redirect within mojoPortal had I known how, which would have resulted in a 301 since there's no 302 redirecting in mojo. This is the path of least resistance for many, especially those who don't want to dive into IIS and the nuances of 301s and other types of redirects. (You mean there's more than one kind of redirect?)
Third, IIS6 doesn't even show the 301/302 terminology in its UI, so it's really easy to use the wrong one, especially since 301 is apparently the default.
So let's say you made the mistake I made. Honest mistake. Or, let's say you briefly renamed a page in mojoportal, then realized a bit later you wanted to rename it back the way it was (you still have to visit the redirect manager in mojoPortal to undo the first redirect).
So now, everyone who has visited your site since the mistake is now irretrievably unable to ever use that URL to reach you again! You have no way to fix them in any sort of automated fashion. Does that sound like reasonable behavior? You essentially black out ever being able to use a URL again when you issue a 301. That certainly doesn't seem like what most webmasters intend, it's not the way things used to be, and now it's just too bad. I don't know about you, but all of a sudden I don't ever want to use a 301 again if I want to maintain control over my namespace. There's a real difference between saying "hey google, I want you to start linking to this new url instead of the old one" (which is what 301s are good for) and saying "hey, I want to permanently and irretrievably invalidate this url from being used on my site again." The latter is what it means now, and it didn't before.
All right, so I've slightly overdramatized the irretrievably lost url thing. But only a little. The point is, it's still lost to your control. There is a way to get the browser to come back to your site. Clear the cache, right?
Wrong. IE9 clears the cache completely...of everything except the cached redirects. What? There's no way to clear the cache using the normal cache clearing controls. You can even reset IE to total defaults...still no luck.
There are two solutions...either go into IE9 private mode (Ctrl-Shift-P) and visit the url, or use the great http debugger Fiddler to clear the Wininet cache (under Tools). Now you can get back to the url in regular IE.
Not only is this a ridiculous oversight by the IE9 developers, even if it were a real solution, you'll be lucky if your users bother to ever call you to say they can't visit your important URL. Telling them to clear the cache is a bad enough "solution". Walking them through one of these other workarounds is a nightmare if you expect to do actual business over your site.
So, I propose some alternatives for solutions:
a) Stop using 301s on mojoportal and use 302s instead
This isn't a great solution since presumably 301s help your search indexing by telling Google that yes, this url really moved somewhere else.
b) Issue "Cache-Control: no-cache" headers on all 301s
This is probably more reasonable. IE9 and FF will respect the no-cache directive and check back with the server every time the user visits the URL. This is, at worst, equivalent to the old behavior. The IE9 developers may see this as subverting a good user experience, but I see it as maintaining control over my namespace. I've already lost one very valuable url ("downloads.aspx") to their "performance enhancement").
c) Issue "Cache-Control" headers with a cache timeout on all 301s
This is the middle-of-the-road solution. The redirects will be cached, but will also expire. The two problems I see with this are: first you have to educate the mojoportal admin that this setting even exists and what it does so they can have an opinion of what's a reasonable setting. Second, you're not going to want to set this to anything more than a couple days, and even then, what are you going to tell your users for whom it breaks? Wait a couple days, or go into private mode? They're going to take the easiest alternative: don't bother trying to buy your product.
Here are the articles I found on this topic:
Ted