For a business request we need to fix the incorrect HTTP response code for our 404 Page not found and 500 Internal server error page.
I am not big fans of Java / JBoss and I am not familiar with how ATG manage HTTP response code for page. But I know our vendor should have configured the basic error page handling in the web.xml stating the jsp pages (a.k.a. 404.jsp and 500.jsp) for the mentioned error. But the way our vendor implemented causing the error page has a 302 Temporary redirect / Moved temporarily response code because of a page redirection happens on both 404.jsp and 500.jsp
I have been questioning why should there be a page redirection in those 2 files for another 2 jsp that render the real pages. So I remove the redirection and put all real content to those error page.
And recently we discover those 2 error pages don’t have multiple site aware. We fail to use ATG Targeter or receive anything that related to multiple site. My backend developer buddies figure out it probably be the request does not pass through ATG application result in the lost of those information. And we might need to build some Java component to perform the missing part.
This puzzled me that it shouldn’t be that complicated as this is something fundamental for Apache Server and other programming like PHP. That must be something we can configure that properly and get the work done.
Thanks for the credited site: http://quest4atg.blogspot.hk/2012/07/error-codes-some-of-frequently-issues.html which shows me not only the proof my backend buddy mentioned (the request hasn’t passed through the ATG pipeline, and multiple-site information are given by that pipeline process), but also provided the way to configure the JBoss web.xml file.
1. Define the filters
2. Define the filter mappings
3. Include all the error page elements
Setting these configuration can help bring back the multiple site information for the error page rendering (SO that we can provide different content in the error page like proper cross-sell items and corresponding support-contact information.
But how about if there is people / search engine direct accessing the 404 / 500 JSPs? Right now we still need to depend on a Java code in the beginning of those JSPs to dispatch the corresponding error code:
<% response.setStatus(404); %>
<% response.setStatus(500); %>
For the 404 page, fire 404 is fine. But for the 500 page, our SEO manager wishes it to be 404 as well for direct accessing that 500 JSP, which is still an outstanding task for me. As if I apply the setStatus(404) to the 500 page. When a real 500 error happen, the original 500 status code will be reset to 404 by that java line… Still another long way to go for this discovery~