rdb: How to generate a real 404 HTTP header status within RedDot LiveServer
|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">
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:
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.