How to to generate a real 404 HTTP header status within RedDot LiveServer / Open Text Delivery Server – Process DynaMent and Apache

Todays post is written by guest writer Alexander Seidel, RedDot/Open Text Consultant at webit! in Dresden, Germany. He is working for clients like Deutsche Post, Volkswagen and Telekom Systems. He likes fiddling around with Open Texts Management / Delivery Server systems and bringing projects to a better technical level.

You publish content to the LiveServer, Google indexes it, you delete it, but Google (or any other search engine really) still indexes the page. However when you visit the page it doesn’t exist and you just see a 404 page. What happened? You start investigating with Firefox and the Live HTTP headers add-on to see what happens when you open an URL with non-existent content.

200 OK is not OK for a 404 page

The Firefox add-on will eventually show you that the pages response header returns a HTTP status 200 OK and your, hopefully existing, page not found message. What did you expect instead? The same that Google would expect. A proper HTTP response header status 404 and your page not found message.

After looking around for a solution I set up a little hack. I created a new page (e404.html) in RedDot LiveServer Open Text Delivery Server with the following content:

<rde-dm:process mode="redirect" url="http://your_domain/error_404.html" type="http" status="404">
  <rde-dm:include content="http://your_domain/error_404.html"/>
</rde-dm:process>

The process Dynament can set the HTTP status. Its intended for use with 3xx for moved pages, so it has an URL parameter for the HTTP location header. I changed the status to 404 and I used the error page URL for the URL parameter because it is an obligatory value which needs to be filled in.

The process Dynament allows child elements. That’s the place where I included the real page not found message.

Finally I’ve set the e404.html page as the content not found event in the RedDot LiveServer project configuration (make sure you don’t select the redirect checkbox!). And voila, I’ve got a working 404 error and my page not found message.

One last bit remains. The hack above will still return the following as part of the response header information:
Location: http://your_domain/error_404.html
which is useful for 301 or any other moved page but not a valid information for 404 errors.

Apache mod_headers to clean it up

Using a simple mod_headers modification within Apache can remove the invalid line above from the header data.
Since we don’t know the name of the removed file we have to use a regular expression and instead of using ‘Header unset location’ we can used ‘Header edit’ to fix this.

Just add the following line to your Apache configuration file.

Header onsuccess edit Location ^.*http://your_domain/error_404.html.*$ ""

This will rewrite or furthermore delete your location header to an empty location header. And apparently Apache seems to throw away the empty header returning a proper 404 page with correct header status.

Check your 404 page again using Firefox as described above and you will now have a real 404 error page with your page not found message and correct response headers.

How do you solve this in your LiveServer installation?
How would you do it when using IIS and Helicon as described here?

Share and Enjoy:

How to set MIME types in RedDot LiveServer / Open Text Delivery Server – It’s easy if you have the DynaMent

Have you ever tried to deliver anything else than HTML files with your LiveServer? Well, in case you have one of the fancy Open Text Delivery Servers and you have set up the webserver properly (as described here) they should run fast and stable.

For what would I use this trick? RSS feeds!

Now you have for example a RSS Feed to publish but the page doesn’t work in Internet Explorer. Or maybe the XML doesn’t show up properly in Firefox? Eventually you have to find out that the MIME Type is wrong. The reason is that the default MIME type in RedDot LiveServer is set to “text/html”.

Now all you have to do is change it. Lucky there are some RedDot consultants here to help you with this!

How do you tell Delivery Server what MIME type you want?

Whenever you want LiveServer to return something as XML file you have to add a DynaMent to your RedDot CMS content class.
For the correct rendering of your content add this DynaMent at the top ! of your content class:

<rde-dm:attribute mode="write" attribute="request:rdeResponseMimetype" op="set" value="text/xml"/><?xml version="1.0" encoding="utf-8"?>

Tell the DeliveryServer that your MIME type is “text/xml” you will get a proper XML file delivered to all browsers requesting this document.
What other tricks and tweaks do you have for the Open Text DeliveryServer / RedDot LiveServer?

Share and Enjoy:

About the Author

This article is based on the blog post here of Danny Baggs. Danny has a strong developer based background and is working for Open Text.

Overview

The way the LiveServer Delivery Server is set up for a development environment usually is as a standalone application without having a front controlling web server. Although this is working for development purposes it doesn’t work within a live environment with several thousand users firing off HTTP requests every hour or minute or even second.
This post discusses the best practice of deploying the Open Text Delivery Server in an optimal way alongside a front controlling web server. This article provides a high-level overview of what to set up and how the necessary components work together. Depending on feedback I may post further posts on the details of each step.

After reading this article you will know

• How to set up your LiveServer environment properly to ensure it is scalable, reliable and offers high performance
• Which tools you can use to create dynamic functionality
• How you can tweak your LiveServer to gain some SEO enhancements

How does Delivery Server work and what should you not do

The Open Text Delivery Server is a dynamic web server component that has strengths in coarse grained personalization and dynamic behaviour as well as system integration. All you need to know is where to get your hands on and what to do and what you better should not do.
The Open Text Delivery Server is housed within a Servlet Container. A Servlet Container is not the ideal location from which to serve static content. It handles requests in a way that limits the amount of concurrent requests. This can lead to severe performance issues.
There are ways to mitigate this but it needs quite a lot of Java experience and is still not recommended. Unless you wish to maintain a level of access control over the static content let’s put it simply like this:
Don’t run the Deliver Server as a standalone web server.

Next: What do you need to get Delivery Server running?
Read more »

Share and Enjoy:

Reddot CMS Consultants / RedDot LiveServer Consultants
RedDot beads – Where else would you find them?

This is a non-technical article, you can skip it or skim it to get an idea how to get experienced RedDot staff and/or more traction for your RedDot business. Beside these facts this site is a big teaser page to our job and RedDot project work section.

You might have come across the RedDot CMS consultant corner we’ve set up here a few months ago.

Have you seen the RedDot Consultant job corner?

If you are looking for a LiveServer consultant, a RedDot Contractor to solve your CMS project tasks or a worldwide group of Open Text Partners you wish to respond to your Request for Proposal then the job section is the right place for you.

Are you a RedDot CMS Consultant looking for work?

If you are a RedDot CMS consultant and want to upload your profile fee free to do so. There are plenty of new project out there waiting to get done. Why not publishing your CV and your RedDot CMS consultant eperience and get more job enquiries? Every you will get people visiting this site. Placing your Reddot Consultant profile up here is the next logical step to push your reputation.

Do you need a RedDot LiveServer Consultants?

If you are looking for a RedDot LiveServer consultant and want to advertise your job you can easily do that too. LiveServer experience is rare these days and there are a few chosen RedDot CMS and LiveServer experts out there able to help you. If you can’t find them here it is unlikely you will find them somewhere else.

Open Text RedDot Web Solutions Experts find and search projects here

Are you looking for the right ressource to complement your team? Do you have project work?
Would like to get an overview which capable RedDot agencies and consultants are out there and available for you?

Our visitors are the elite of Open Text consultants. They are exchanging ideas, solutions, tipps and tricks every day on this site from all over the world. This gives you the opportunity to find the matching development and consulting ressource in your country but also compare worldwide market rates.

RedDot CMS consultant work can often be done remotely and doesn’t necessarily require onsite work during the whole project cycle. A project can be set up and tested locally, then being imported to your UAT environment. You can have a RedDot consultant working for you from everywhere on this planet. All you need to do is find them.

Oh and yes, it’s free. Uploading your profile, adding a RFP(Request For Proposal) or entering any sort of RedDot job description is generally free of charge. You can get your own login and participate on the forum. You also can get us to do the work for you and it is still free.
Have a look at it, now.

Share and Enjoy:

Guest writer Marek Korch, RedDot/Open Text Consultant at infinity-group.pl in Poland and working for clients like BNP Paribas Fortis, Dan-wood, Allianz and Nordea. He enjoys new challenges in Open Texts Management / Delivery Server systems and learning new things around the ECM world and how to improve them. He also just started writing on this blog.

In this article we will show you how to find the right files to extend Open Texts Delivery Server (formerly known as RedDot LiveServer) with your own Java classes.

You might have worked with LiveServer DynaMents before and sometimes you just wish you would have that special method or a nicer way to process this bit of information but the existing set of Delivery Server DynaMents just doesn’t exactly fit your needs. Therefore here comes your LiveServer tutorial for including your own Dynaments inside of LiveServer.

If you want to start your own adventure with DynaMents and inline Java functions which will extend the DynaMents functionality, you’ll need to go through the following steps:

1. Prepare the LiveServer (Delivery Server) environment
2. Prepare the java package and the java class files
3. Create your own class which you want to use to extend the built-in java classes

Prepare the LiveServer Delivery Server environment

First of all check your Delivery Server version and build. I was working on LiveServer (Delivery Server) build 4.0.0.8 but it’s recommended to upgrade it to LiveServer 4 SP1. Of course it is not necessary to upgrade your LiveServerS/Delivery Server, but it makes things easier if you are able to go with the upgrade as you will see below. (Always keep in mind to check the release notes and check issues affecting your environment. LS 4 for example has a known defect with updating/connecting to Active Directory which is yet about to get fixed)

Prepare the java package and the java class files

Finding the classes on your LiveServer environment can be a bit tricky, to create your own Java class file you will have to import one very important class package which is built in the LS. The class is called:
de.reddot.xmaps.dynament.DefaultInlineFunctions;
There are two ways to find it and to import into your class package during the compilation process:

A) Especially recommended to use if you have LiveServer without SP1, is to import the above mentioned class into your java project in which you will compile your own class. To accomplish that, simply import the JAR file with the necessary class which is located in
<LiveServer_Install_Directory>\\tomcat\\webapps\\cps\\WEB-INF\\lib\\rdls-rde-x.x.x.x.jar
x.x.x.x corresponds to a build version of LS. In my case it was rdls-rde-4.0.0.8.jar.

B) If you already have LiveServer running with the SP1 updgrade, you can find the necessary class in
<LiveServer_Install_Directory>\\tomcat\\webapps\\cps\\WEB-INF\\classes\\de\\reddot\\xmaps\\dynament\\DefaultInlineFunctions.class

Create your own class which you want to use to extend the built-in java classes

The Next step is to prepare a definition of your own class. It should looks like this:

// ############################
package com.company.package;
import de.reddot.xmaps.dynament.DefaultInlineFunctions;
public class ExtendedInlineFunctionsClassName extends DefaultInlineFunctions{
         public String function(String value, ...ANY OTHER VARS DESIRED){
                   String mustReturnAString=value;
                   return mustReturnAString;
         }
         //called inline like [#source:attribute#].function(...ANY OTHER VARS DESIRED)
}
// ############################

After that, all you have to do is to compile your own class file with your function(s) and then copying it to to the classes folder on your LiveServer directory:
<LiveServer_Install_Directory>\\tomcat\\webapps\\cps\\WEB-INF\\classes

And Voila! Based on that you are ready to go. Create your own Java methods and use the according DynaMents in your LiveServer project.
Questions? Ideas? More LiveServer enhancements? Use the comment box below!

Share and Enjoy: