Hi Joe, we uncovered a strange one here, involving 301 redirects and possibly the content version history. One of our content editors was tasked to add a blog post to our main site. Instead of adding a new post, she instead overwrote an older post. When she realized what she had done, she used the "restore to editor" functionality to recover the original blog post, and then created the new post. When she was all done, she found that when navigating to <siteroot> she was being redirected to the old blog post. I investigated and found that the system had added a 301 redirect from <siteroot> to <siteroot/old_blog_page.aspx>, at some point during her changes. Needless to say, because of 301 redirect caching, this could have been a major issue. Fortunately, we caught it quickly, so we don't think very many visitors were affected.

She can't remember the exact sequence of steps she used. I've spent some time trying to reproduce this, but haven't been able to come up with an exact sequence to trigger it. Sorry about that, I know how tough it is to find a bug without reproduction steps.

But as a workaround, I think a prudent "failsafe" measure would be to ensure that the "from page" is not blank or null before any 301 redirect is created. If anyone needs to redirect from the site root level, I'd think it would be better to handle that in IIS than in mojoPortal.

As a workaround on our side I'm also going to implement the keys to limit the browser cache time of 301 redirects as well.

Thanks,

Jamie