nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Cache case sensitivity problem in livesite

ben_a

Not sure what livesite version we have, but our TS is 7.1.0 and they were installed together.

My problem is this. If I publish a page like:

/mysite/mypage.page

but then request it from the server as:
/MySite/MyPage.page

a unique cached version is created for both URLs.

If I republish the page from teamsite, the all lowercase (or however it is cased in teamsite) page will be refreshed, but the mixed case URL will still be the older cached version of the page.

The cache only flushes the matching case version in livesite, but leaves any number of "orphans" based on how they were requested. Invalidate Runtime Cache has no effect since it sends a case sensitive request to the server.

This causes there to be 2 or more versions of the same page available on livesite.
/mysite/mypage.page is the updated version since the cache flushed when it was published
/MySiTe/MyPaGe.page is an old outdated version that is cached still since the cache seems to create an instance for any combination of uppercase/lowercase that you request the page as.

The only workaround I have is to republish the sitemap file, since that seems to flush all cached pages. This is not an ideal solution.

Our livesite server is running on IIS 7.

I'm not the sysadmin, but I have more time to troubleshoot the problem than he does, so I was hoping to find a solution I could provide to him.

I'm hoping there's a simple way to make livesite case insensitive.

Thanks for any help!

Find more posts tagged with

Comments

GRD

This is a good one, Ben, and definitely a bug. I just tried that same test in an un-patched 7.2.1 LiveSite/Windows system with the same result.

Can you please open a support ticket with Autonomy?

BTW, you can manually clear the cache at:

http://runtime-server/iw/admin/JCS.jsp

-Greg

ben_a

Our engineer opened a ticket and was told that there wasn't a settings fix and that it could be considered for future versions.

Problem is, this puts us at great risk from a compliance standpoint. I run a bank website and we could be held accountable for incorrect or outdated information showing up on the website.

I was told to only use "Somepage.page" in my links (always use the same case), but how do I control how google or others present my links?

As it stands now, a web visitor will potentially see the older version of my page if they come in using a different variation of the page name. I told our engineer that if there's not a fix or patch, we will have to look at another CMS. This simply puts us at too great a risk. Flushing the cache manually is not a workable solution. It leaves too much to chance.

Edit: I have thought that if the cache could be flushed as part of workflow, this would be a temporary fix. Obviously it's never desirable to flush the entire cache. That defeats its purpose. We make edits all day long, so it might negatively impact performance if we went this route.

GRD

Clearly an oversight on the Autonomy side, and I agree unacceptable. I am getting ready to lead a very large LiveSite project that will be on the Windows platform, so this is of particular interest to me.

Have you investigated any way to make IIS7 case sensitive?

-Greg

ben_a

Our engineer proposed a rewrite rule to lowercase all URL's, but that won't solve the problem since our folder and filenames are uppercase/lowercase.

If all URL's are rewritten to lower, then:

Somepage.page will be served as somepage.page which seems OK at first.

But, workflow/OD will only clear the cache for Somepage.page, so the IIS rewritten URL will be an old, orphaned version. In fact, the page will never appear updated since the rewrite rule forces you to the orphaned version no matter what. Only a cache flush would fix that.

Rick Poulin

I was told to only use "Somepage.page" in my links (always use the same case), but how do I control how google or others present my links?

You can "strongly suggest" by using canonical links. However, in your situation this is probably insufficient.

Our engineer proposed a rewrite rule to lowercase all URL's

That's probably as good an idea as you're going to get, but it does involve some content migration (file renaming) which gets painful if you already have tons of content. But, along the same idea, what you could do is use a servlet filter (in Java, ahead of LiveSite's), to resolve the URI's target on the filesystem and, if the case doesn't match, force a 404. The obvious downside to that versus blanket lowercasing is the performance hit of doing that extra I/O on every single request.

GRD

This is not really an IIS or Tomcat/app server problem as Tomcat just passes "/*" to LSDS if there are no other matches (*.jsp, for instance). Thus the problem is in LSDS itself.

You could probably write a simple servlet filter to check and see if the file exists, and then redirect to a standard 404 page. This may be the most elegant solution.

-Greg

(Topic_39922)OS_BIRT_2.6.2_FirstDayOfPreviousMonth.rptdesign

ben_a

My engineer has informed me that a fix is coming in a future version. So I've got that going for me. :-)

Bowker

In the mean time I like the idea others have suggested.

Put in a Sitewide Pre-Controller that will:
Grab the URI, One folder at a time walk down the path and correct any upper/lower case issues with the URI. If no changes were made, return null. If the URI was changed pass back a redirect to the right page. You could either just return the right page or send a 302 back to the browser.

If you site is very active, you may notice some performance issues. in that case you could cache the before and after results with the assumption that someone may ask for the same thing again.

Simple Sparkline.rptdesign